My machine is a SunBlade 1000 with an XVR-1000 (FFB3) in it. Whenever
I run any JOGL demo I get a lot of flashing. It appears that the window is
being created using a single-buffered visual rather than a double buffered one.
I think I understand why this is happening.
Here is some mail I exchanged with Ken Russel on the topic:
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:
-
The J3D program calls J3D to get the “preferred” GraphicsConfiguration
(J3D also provides mechanisms for users to select a GraphicsConfiguration
with desired capabilities). -
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.