This is the mail archive of the
mailing list for the Cygwin XFree86 project.
Re: X hardware acceleration still flaky?
On 12/08/2010 19:20, L.Wood@surrey.ac.uk wrote:
I can confirm that under the current Cygwin release, with your original XWin debug code and geomview running with opengl support enabled and SaVi animating the Geomview window and forcing camera updates:
moving the geomview window up and/or to the left causes the crash,
while moving it down and/or to the left constrains the updated area to the overlap of the current window position with the original viewport (if that's the right term) - hard to spot amongst the flickering, and I missed that. Apologies.
So, yes, it's not related to use of a second monitor; I was moving the geomview camera up to that monitor to get the crash.
I can confirm that your replacement code drop (url below) appears to fix this crash problem.
Thanks for testing.
However, I have a question about your conclusion that this has nothing to do with opengl.
If you start geomview under a buggy crashing XWin server with:
geomview -noopengl (one dash, note spelling)
there's no flickering or crashing; drawing is always slow and reliable, even under a buggy XWin. From that, it's a pretty easy conclusion to presume that OpenGL is somehow involved? Or is only one of the geomview drawing methods (the one that just happens to use OpenGL) at fault with the composite extension?
Whilst this is the obvious conclusion to reach, it doesn't seem to be correct.
Supplying -noopengl to geomview causes it to do different things, and in
particular, it creates a different window hierarchy inside the camera window
(which you can observe using xwininfo -tree on that camera window). It seems
that the window hierarchy used when opengl is selected, happens to expose a
bug in XWin, which causes composite to handle the window's position incorrectly.
Volunteer Cygwin/X X Server maintainer
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html