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/