X / gtk-x11 / flicker and other problems [+PATCH]

[Jon TURNEY]

John Emmas wrote:
> ----- Original Message ----- From: "Jon TURNEY"
> Subject: Re: X / gtk-x11 / flicker and other problems
>>
>> btw, I use -multiwindow mode all the time, but I've obviously trained
>> myself not to see any of these artefacts
>>
> lol - fair point..!   But I must admit, having seen how the graphics
> performance can be under gtk-win32 I'd be very reluctant now to go back to
> x11, even though I know it must be more sensible to stick with the official
> backend.  Here's some expansion on what I said earlier:-

Bah! Now I've noticed the flickering again, so I have to fix it.
Your cunning plan worked. :-)

>>>  Twin monitors are a bit of a pain too, to be honest.
>>
>> Would you care to elaborate on this point a bit?
>>
> One particular problem is that the xserver will only support twin monitors
> if they both have the same settings (resolution etc).  I happen to use my
> primary monitor at 1600x1200 and my secondary monitor at 1280x1024.  
> Running
> the monitors at different resolutions is a lot more common than you might
> realise.  At one time I thought I was pretty unique but in fact, most
> dual-headers that I've spoken to also have their monitors at different
 > resolutions.

Hmm... I thought this worked.  The only restriction should be that the 
colour-depth of the monitors is the same...

> Another problem (doesn't affect me but I think I read this
> somewhere) is that Cygwin's xserver isn't very hapy if the primary monitor
> is on the right-hand side.

The internet is full of lies :-)
That bug should be fixed.

>> The way the integrated window manager works at the moment, when a window
>> is being resized WM_SIZING is only used to enforce any window sizing
>> constrains specified in hints, that isn't passed onto the X 
>> application to
>> allow it to redraw itself until the mouse button is released and a 
>> WM_SIZE
>> is sent.
>>
> Yes, that ties in with what I'm observing.  Interestingly I just booted up
> into Linux and rebuilt the same app using x11 on Linux.  That gives
> more-or-less the same result as Cygwin-X.  The window contents don't get
> redrawn until I either release the mouse button (or in Linux's case, stop
> dragging for more than about a second).

Hmmm... playing around a bit more with the resize, if you grab the window 
frame and resize it moving the corner of the frame repeatedly around and 
around in circles, it's quite noticeable when the mouse button is finally 
released that a backlog of ConfigureWindow requests has built up and then get 
processed.  Don't know if this indicates something is in the wrong thread, if 
we just need some backpressure to prevent this queue building up, but this 
isn't right, and needs fixing....
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cygwin-multiwindow-flicker.patch
URL: <http://cygwin.com/pipermail/cygwin-xfree/attachments/20090212/3b597f94/attachment.ksh>
-------------- next part --------------
--
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/