Bug 39

---- 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