On 12/08/2010 19:20, l.w...@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.
--
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/
