Re: Probable bug in WGL implementation (AIGLX) of GLX calls in XWin -wgl

[Jon TURNEY <jon dot turney at dronecode dot org dot uk>]

On 01/10/2012 22:34, Tim Edwards wrote:
>    I have a tool I maintain called "magic", a VLSI layout editor.  One
> of its nicer features is a graphics mode based on OpenGL.  Occasionally
> I generate Cygwin versions of it, and was delighted to discover on my
> last update of Cygwin that there is a support for hardware-accelerated
> OpenGL using some translation between GLX and WGL calls at the level
> of the X server.  I tried using this with my Cygwin version of magic,
> and for the most part it works.  But it does have the strange effect
> of overwriting the OpenGL window with contents of other windows.
> 
>    My setup is very non-standard but works under Linux and OS-X.  The
> application is built as an extension of Tcl/Tk.  Because the application
> makes all the OpenGL calls from C routines, it generates a generic
> window using a call to Tk_CreateWindow(), and maps it using Tk_MapWindow().
> The returned window is then passed to glXMakeCurrent().  All of this
> works fine.
> 
>    The window that is used for the OpenGL rendering is framed by
> scrollbars on the side and bottom that are "canvas" windows in Tk.
> What I am seeing is that any time the scrollbars are redrawn, the
> OpenGL window is over-drawn, looks like with the default Tk background
> gray color.  A similar thing happens if I pop a window on top of the
> OpenGL window;  when I pop it down, the image of the window remains
> in the OpenGL window.  I presume that in the way GLX is supposed to
> work, X11 has reserved pixmap space somewhere for the window, but
> once the call to glXMakeCurrent() has been made, the contents of this
> pixmap should not show up on the screen.  Yet that is what I am seeing.
> Any clue as to what might be going on? 

Yes, unfortunately.

The current implementation of GLX using WGL takes a few shortcuts, basically
anything that is drawn with OpenGL isn't composed into the screen, it's just
drawn on top of it.

This works well enough when the GLX window is a top-level window, or is
non-top-level and has no occluding relatives and is drawn after anything it
occludes, but mis-renders in more complex scenarios.

This is discussed a bit more in [1]

As mentioned there I have done a bit of work fix the mis-rendering in some
cases.  I can't quite tell from you description exactly what's going wrong, so
I am not sure if those changes are going to help in this particular case.

I have built a test release including the changes discussed there, available
at [2], if you would like to test if it makes things better/worse/no difference.

The proper solution is probably something like rendering the OpenGL to an
offscreen buffer, and then composing it into the un-occluded area of the
window, but that is considerably more complex to implement.

>    One I tarball up this version of magic, I can send a pointer to
> where it can be obtained if anybody wants to download it and test
> for the bug.

Thanks.  This would be useful as a test case for any future work to improve this.

[1] http://sourceware.org/bugzilla/show_bug.cgi?id=10472
[2] ftp://cygwin.com/pub/cygwinx/XWin.20121012-git-3807fe48a7282459.exe.bz2

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/