This is the mail archive of the cygwin-xfree mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: X hardware acceleration still flaky?


Jon,

thanks for looking into this.

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.

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?

somewhat enlightened but also somewhat puzzled,

thanks,

L.

SaVi satellite constellation visualization: http://savi.sf.net/ 

-----Original Message-----
From: Jon TURNEY [mailto:jon.turney@dronecode.org.uk] 
Sent: 12 August 2010 18:51
To: cygwin-xfree@cygwin.com
Cc: Wood L Dr (Electronic Eng)
Subject: Re: X hardware acceleration still flaky?
Importance: High

On 10/08/2010 12:00, L.Wood@surrey.ac.uk wrote:
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to thread 5736.0x16c4]
> 0x6fb96c8d in pixman_fill_sse2 () from /usr/bin/cygpixman-1-0.dll
> (gdb) bt
> #0  0x6fb96c8d in pixman_fill_sse2 () from /usr/bin/cygpixman-1-0.dll
> #1  0x6fb97205 in pixman_fill_sse2 () from /usr/bin/cygpixman-1-0.dll
> #2  0x6fb77245 in pixman_fill () from /usr/bin/cygpixman-1-0.dll
> #3  0x0044924b in fbFill (pDrawable=0x109306f8, pGC=0x10936530, x=657, y=367,
>      width=450, height=450) at fbfill.c:48
> #4  0x0044746f in fbPolyFillRect (pDrawable=0x109306f8, pGC=0x10936530,
>      nrect=0, prect=0x1096791c) at fbfillrect.c:77
> #5  0x0052728f in damagePolyFillRect (pDrawable=0x109306f8, pGC=0x10936530,
>      nRects=1, pRects=0x10967914) at damage.c:1404
> #6  0x005504c3 in ProcPolyFillRectangle (client=0x106bd4f0) at 
> dispatch.c:1939
> #7  0x0054c56e in Dispatch () at dispatch.c:439
> #8  0x005465af in main (argc=3, argv=0x61227b64, envp=0x104300f8)
>      at main.c:286

Thanks.

With the details provided in the last couple of emails, I have managed to reproduce what I think is the same problem as you are seeing.

1) Start geomview
2) Cause the geomview camera window to start animating, e.g. by loading one of the demo scenes and making the camera rotate, or by opening SaVi and starting simulated time running
3) Move the camera window away from it's original position up or to the left (observe if you move it a small amount to the right or down, the area of scene being drawn in it which is updated is constrained to the original window position)

This has nothing to do with 'hardware acceleration' or OpenGL, it seems that the particular way this application draws it's output (into a same-size child window of the camera window) interacts with the composite extension to expose a bug in the XWin code.

You should be able to workaround the crash by starting the X server with '-extension Composite' to disable the composite extension.

I've uploaded a build with an attempt at fixing this at [1].  Perhaps you could try it out and see if it works for you?

I'm not sure why the image flickers so badly, a double buffered OpenGL visual seems to be being used, so only a complete frame should be transferred to the display, but I can see elements of the scene being drawn.

[1] ftp://cygwin.com/pub/cygwinx/XWin.20100812-git-7180c693de178032.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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]