---- Reported by deronj 2003-09-10 16:47:05 ---- 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. ---- Additional Comments From kbr 2004-04-30 15:52:32 ---- 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. --- Bug imported by sgothel@jausoft.com 2010-03-24 07:45 EDT --- This bug was previously known as _bug_ 39 at https://jogl.dev.java.net/bugs/show_bug.cgi?id=39