jogl
  1. jogl
  2. JOGL-39

Window creation in JOGL is dependent on visual order

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: current
    • Fix Version/s: milestone 1
    • Component/s: jogl
    • Labels:
      None
    • Environment:

      Operating System: Solaris
      Platform: Sun

    • Issuezilla Id:
      39

      Description

      JOGL programs flash on my FFB3 device (latest patch) because the window is
      getting created with a single buffered visual.

      Here is a discussion with Ken Russel which has the details.

      Ken writes:

      > What
      >happens if the OpenGL context's selected visual and the widget's underlying
      >visual (if there is one – I'm not clear on how this works) don't match? Is
      >this what's happening, so that the OpenGL context is being constrained to the
      >limitations of the widget's visual when it's made current?

      I believe this is precisely what is happening. After talking to the
      FFB3 DDX engineer I now understand why I am seeing the flashing when no
      one else is. The reason is because, on most devices, the double buffered
      24-bit gamma corrected visual (the one JOGL prefers) comes first on the
      X visual list. When AWT (or 2D or whatever) creates the 24-bit window
      (I'm still not sure how it knows the window is 24-bits) it uses the
      first visual encountered. For most devices this works. But it turns
      out that the ZFB family of devices (FFB3, Zulu, and DhakaZulu) are different.
      Recently, the DDX engineer for these products was asked to reorder the visual
      list to put the single buffered visuals first (to address some other problem).
      So on my FFB3 device, the window is created in a single buffer visual.

      What this suggests to me is that the current method that JOGL programs use
      to create the window and the context has a dependency on the order of the
      visuals in the visual list. I don't think we want the current scheme to
      persist because we have no control over the visual orders of the various
      platforms JOGL supports. And visual orders may change over time.

      I think we need to modify the way that JOGL programs create their window and
      context in order to eliminate this visual order dependency. The method that
      Java3D uses could serve as a possible guide. Here is what Java3D does:

      1. The J3D program calls J3D to get the "preferred" GraphicsConfiguration
      (J3D also provides mechanisms for users to select a GraphicsConfiguration
      with desired capabilities).

      2. The program creates a Canvas3D using the Graphics Configuration. (I'm
      guessing that this creates both a window and a context--Dan Petersen
      can probably confirm this).

      The GraphicsConfiguration class acts as an abstraction for a visual.
      If the JOGL user were to choose the GraphicsConfiguration first and then
      use this to create both the window and context (via a JOGL API call) then
      the visual order dependency problem would go away.

        Activity

        Hide
        kbr added a comment -

        The X11 visual selection code has been rewritten as of JOGL 1.1 beta 01. This
        issue should now be fixed. Please reopen this issue or file a new one if not.

        Show
        kbr added a comment - The X11 visual selection code has been rewritten as of JOGL 1.1 beta 01. This issue should now be fixed. Please reopen this issue or file a new one if not.

          People

          • Assignee:
            jogl-issues
            Reporter:
            deronj
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: