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

OGL: render on a single thread for improved reliability and performance

    XMLWordPrintable

    Details

    • Type: Enhancement
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: 5.0
    • Fix Version/s: 6
    • Component/s: client-libs
    • Labels:
    • Subcomponent:
      2d
    • Resolved In Build:
      beta
    • CPU:
      generic
    • OS:
      generic, solaris_9

      Description

      The OGL-based pipeline added in 5.0 is not as reliable as it could be. A
      typical (native) OpenGL app has one and only one rendering thread, so all
      OGL commands are issued on that single thread. The OGL-based Java 2D pipeline
      doesn't have it so easy because rendering requests can come from any number of
      threads (the EDT, a user thread, etc) even though we try to teach developers
      to avoid doing heavy rendering to hardware surfaces from many threads. It is
      possible to write an OpenGL app that renders from multiple threads, but you
      have to take many precautions to make that app reasonably robust, such as:
        - ensure only one thread is calling OGL methods at any given time
        - use FBConfigs and contexts only from the thread on which they were created

      We went through great lengths in 5.0 to adhere to these restrictions, but in
      the end we can only be as robust as the OGL drivers underneath us, and in
      many cases those drivers are not very reliable when many rendering threads
      are in use at the same time. There is also a performance issue here because
      for any given rendering operation, we need to first fetch the appropriate
      context from thread-local storage (this is usually pretty fast, but it would
      be nice if we could avoid it altogether).

      We could make the OGL pipeline much more reliable if we played nice like
      those typical native apps that only render from one thread. One solution
      would involve enqueuing rendering operations (or any operation that talks
      to OpenGL) on a buffer, and then having a single separate thread that is only
      responsible for flushing that buffer periodically. This would allow any
      number of Java-level threads to issue rendering requests, but in the end only
      the single queue flushing thread would be calling OpenGL methods.
      ###@###.### 2005-1-20 00:16:06 GMT

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              campbell Christopher Campbell (Inactive)
              Reporter:
              campbell Christopher Campbell (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: