This is the mail archive of the
mailing list for the Cygwin XFree86 project.
Re: Probable bug in WGL implementation (AIGLX) of GLX calls in XWin -wgl
- From: Jon TURNEY <jon dot turney at dronecode dot org dot uk>
- To: cygwin-xfree at cygwin dot com
- Cc: tim at opencircuitdesign dot com
- Date: Tue, 16 Oct 2012 14:45:46 +0100
- Subject: Re: Probable bug in WGL implementation (AIGLX) of GLX calls in XWin -wgl
- References: <506A0C64.firstname.lastname@example.org>
- Reply-to: cygwin-xfree <cygwin-xfree at cygwin dot com>
- Reply-to: cygwin-xfree at cygwin dot com
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?
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 
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 , 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.
Volunteer Cygwin/X X Server maintainer
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html