Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6477756

GraphicsDevice.getConfigurations() is slow taking 3 or more seconds

    Details

    • Subcomponent:
      2d
    • Resolved In Build:
      b124
    • CPU:
      x86
    • OS:
      windows_xp, windows_7

      Backports

        Description

        FULL PRODUCT VERSION :
        1.5.0_06
        1.4.2 build 1.4.2-b28
        1.6.0-beta2-86
        1.5.0_07


        ADDITIONAL OS VERSION INFORMATION :
        Microsoft Windows XP [Version 5.1.2600]
        Microsoft Windows 2000 [Version 5.00.2195]


        EXTRA RELEVANT SYSTEM CONFIGURATION :
        Occurs on all versions of Windows on single headed machines which we have tested it on. On a double headed Windows XP machine it does not occur.

        A DESCRIPTION OF THE PROBLEM :
        The first time GraphicsDevice.getConfigurations() is called on a single header machine it takes 3 to 5 seconds. If it is called again on the same machine in a different Java session it takes slightly less time. If it is called again in the same Java session it takes a few milliseconds.

        This has previously been reported in 2000 but the bugs are marked as "fixed". A 3 second delay does not sound like "fixed" to us.

        STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
        Run the program supplied which calls GraphicsDevice.getConfigurations().

        EXPECTED VERSUS ACTUAL BEHAVIOR :
        EXPECTED -
        I would expect the program to print:


        Starting....
        Finished in 20 milliseconds


        ACTUAL -
        It actually prints:

        Starting....
        Finished in 3585 milliseconds


        REPRODUCIBILITY :
        This bug can be reproduced always.

        ---------- BEGIN SOURCE ----------
        /**
         * Program to demonstrate speed of GraphicsEnvironment.getConfigurations()
         */

        import java.awt.* ;

        public class Bug
        {
        public static void main(String args[])
           {
                GraphicsEnvironment ge = GraphicsEnvironment
        .getLocalGraphicsEnvironment()
        ;
                GraphicsDevice[] gs = ge.getScreenDevices();
                for (int j = 0; j < gs.length; j++)
        {
        // Demonstrate problem:
        // The first time that getConfigurations() is called
        // it takes significant time.
        // The second and subsequent calls in the same
        // Java session are fast.
        // Examples
        // Windows 2000 1.7GHz Java 1.5.0_06 3355 ms
        // Windows 2000 1.7GHz Java 1.4.2_08 3355 ms
        // Windows XPSP2 2.4GHz Java 1.4.2 2700 ms
        // Windows XPSP2 2.8GHz Java 1.5.0_06 3313 ms
                                // Windows 2000 1.0GHz Java 1.6.0-beta2-b86 3703ms

        System.err.println("Starting....") ;
        long startTime = System.currentTimeMillis() ;
                   GraphicsConfiguration[] gc = gs[j].getConfigurations();
        System.err.println("Finished in "
        + (System.currentTimeMillis() - startTime)
        + " milliseconds"
        ) ;
        }
        }
        }

        ---------- END SOURCE ----------

        CUSTOMER SUBMITTED WORKAROUND :
        Spin up a separate thread which Thread.sleep()s until the main startup has finished and then executes a GraphicsDevice.getConfigurations(). All subsequent calls now complete in a few milliseconds.

          Issue Links

            Activity

            Hide
            vdyakov Victor Dyakov added a comment -
            Re-targeted back to "9" as P2 bug.
            In case this is not a P2 (but P3) can be re-targeted after de-prioritization
            Show
            vdyakov Victor Dyakov added a comment - Re-targeted back to "9" as P2 bug. In case this is not a P2 (but P3) can be re-targeted after de-prioritization
            Hide
            vadim Vadim Pakhnushev (Inactive) added a comment -
            I can reproduce this only when running through the RDP.
            The first DescribePixelFormat takes up about 40-60 ms in any case.
            But in case of RDP all subsequent calls are also takes up that much time, so for 36 total pixel formats reported, this adds up to the 2+ seconds.
            This happens because DPF loads opengl32.dll and then frees it.
            In case of accelerated display it seems that this handle is cached somewhere perhaps in the driver.
            But in the GDI case each DPF call results in loading/freeing a library.
            Caching the handle eliminates this slowness, I need only to find a way to persist this between Java calls.
            Show
            vadim Vadim Pakhnushev (Inactive) added a comment - I can reproduce this only when running through the RDP. The first DescribePixelFormat takes up about 40-60 ms in any case. But in case of RDP all subsequent calls are also takes up that much time, so for 36 total pixel formats reported, this adds up to the 2+ seconds. This happens because DPF loads opengl32.dll and then frees it. In case of accelerated display it seems that this handle is cached somewhere perhaps in the driver. But in the GDI case each DPF call results in loading/freeing a library. Caching the handle eliminates this slowness, I need only to find a way to persist this between Java calls.
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/client/jdk/rev/f4d89e872b3e
            User: vadim
            Date: 2016-05-17 19:54:43 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/client/jdk/rev/f4d89e872b3e User: vadim Date: 2016-05-17 19:54:43 +0000
            Hide
            scfitch Stephen Fitch added a comment -
            If there's a clear reason, for addressing this on JDK 6, and 7, then we can consider backports, but at this time there are no plans to address for JDK 5, 6, and 7.
            Show
            scfitch Stephen Fitch added a comment - If there's a clear reason, for addressing this on JDK 6, and 7, then we can consider backports, but at this time there are no plans to address for JDK 5, 6, and 7.
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f4d89e872b3e
            User: lana
            Date: 2016-06-22 19:53:10 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f4d89e872b3e User: lana Date: 2016-06-22 19:53:10 +0000

              People

              • Assignee:
                vadim Vadim Pakhnushev (Inactive)
                Reporter:
                prr Philip Race
              • Votes:
                0 Vote for this issue
                Watchers:
                9 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: