Bug 842

Created attachment 506 [details]
Test case demonstrating this bug.

GL_CW should be usable as is - without extra (undocumented) commands.  This functionality is central to the application I am currently working on which renders semi-transparent objects, front and back.  The solution of resetting glFrontFace to GL_CCW did work for me.

(In reply to comment #1)
> Created attachment 506 [details]
> Test case demonstrating this bug.
> 
> GL_CW should be usable as is - without extra (undocumented) commands.  This
> functionality is central to the application I am currently working on which
> renders semi-transparent objects, front and back.  The solution of resetting
> glFrontFace to GL_CCW did work for me.

For Bug 826, we started to preserve some states (viewport and texture)
while utilizing the GLContext for an GLSL based vertical flip.

The problem w/ the fixed function pipeline (ffp) is that there might be many states
involved influencing the flipping.

We could either disable it for ffp usage, or let it up to the user
to take care of it, as Bill mentioned.

I would vote for the latter and leave it as-is. But this is surely a matter of taste
and if leaving as-is, we might add some special API doc warning the user upfront.

Shall we discuss this issue with a broader audience ?

Sure .. if somebody is willing to analyze the ffp states and is able to
create such a helper class to preserve those states .. you are welcome.

Until then .. I am undecided.

I think the main trouble is surprise:

In my case my program was totally failing when I switched from GLCanvas to GLJPanel and I ended up writing a test program from scratch to convince myself that GLJPanel actually worked at all, and then started commenting out half of my code in display() at a time until I narrowed it down to the right thing.

This bug is very easy to work around once you know what you need to do, but it is very hard to know what you need to do.

I agree with Mike. In the worst case, it should be documented. I would prefer all states to be preserved in the fixed function pipeline and we could refine this mechanism later if it is too slow. A developer switching from GLCanvas to GLJPanel should not waste tons of time in working around undocumented state changes even though JOGL is open source. The test case mentioned by Mike is quite typical in scientific visualization, I had to do something similar when displaying some geological layers. The current situation is not satisfying. Please Sven, drive those limitations transparent for the developers or document them. Of course I prefer the former solution.

Added 'Warning' regarding GLSL vertical flipping - also added notice about 
how we preserve texture-unit states and the viewport.

I am aware that probably nobody will read those details, 
but at least it is in the documentation now.

I also realize that the mentioned state is a GL-core feature, so not restricted to the FFP.

Alternatively we could use a shared GL context (performance loss while switching),
or drop GLSL flip all-together (performance loss).

I close this bug for now (WONTFIX)  - if you like to re-open it to pursue one of the above alternatives
or another (i.e. preserve all the states) .. please do so. I will merge your changes ofc.

(In reply to comment #5)

I think its fine to not fix it, the problem is confirmed understood and documented, and the workaround is easy. I think it does deserve a mention in the GLJPanel javadoc.

To be honest I'll choose to be a little selfish and write a one line workaround rather than a patch to save / restore all states.

Just for completeness: Best  GLJPanel solution for performance
and compatibility is GLJPanel's 'setSkipGLOrientationVerticalFlip(true)',
see Bug 904, and referenced git-sha1 commits (incl. unit tests).

*** Bug 874 has been marked as a duplicate of this bug. ***