Re: X / gtk-x11 / flicker and other problems

[Jon TURNEY <jon dot turney at dronecode dot org dot uk>]

John Emmas wrote:
> I've been 'tinkering around' with Cygwin for a few months now.  Not doing
> anything serious with it - just finding out about it.  And in the main, I
> like it.  The only disappointment (sorry guys) is 'X11' (or maybe the
> problems are with gtk-x11).
>
> Either way, I've been hugely disappointed at how 'clunky' a GUI app feels,
> on screen.  Moving windows around the screen isn't so bad - but resizing
> them looks horrendous.  Even simple windows flicker very badly.  Another
> problem is tnat the contents don't actually resize until I let go of the
> window.  So, if I'm dragging the bottom-right corner of a window to make it
> bigger, I just get a big white flickery space at the bottom and on the 
> RHS -
> until I let go of my mouse button at which point, all the objects 
> reposition
> themselves.

I'm guessing from this that you are using -multiwindow mode.

>  Twin monitors are a bit of a pain too, to be honest.

Would you care to elaborate on this point a bit?

> A few days ago I realised that GTK+ offers various backends, including a
> win32 one.  So over the past few days I've been taking a look at it - to 
> see
> if I could ditch 'X' and gtk-x11 abd build my Cygwin apps using gtk-win32.
> It's not without its problems but I've been truly astonished at how much
> smoother the windows behave, on screen.  Okay - we'd expect a native build
> to be slicker, but this is sooooo smooth compared to the clunky effects
> that I see with Cygwin-X and gtk-x11.
>
> Before I decide to dive off at a tangent, is there anything I could do to
> 'tweak' the performance of Cygwin's 'X' and/or gtl-x11?  For example, is it
> possible that X11 isn't taking advantage of hardware accelleration?  And if
> so, is this something I could 'turn on' somehow?

There's probably a lot that can be done to improve the performance and 
look-and-feel of -multiwindow mode.  Unfortunately, my focus for the 
foreseeable future is going to be on correctness, rather than performance :S

At the moment, -multiwindow mode always selects the GDI engine for reasons 
which are lost in the mists of time (rooted modes are able to use DirectDraw), 
so a GDI BitBlt is used to transfer the contents of the shadow buffer to the 
display.

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.

That probably explains some of what you are seeing, although playing around 
with this a bit, I think neither of these things is working entirely as it 
should... perhaps -multiwindow mode is allowing default processing of 
WM_ERASEBKGND

btw, I use -multiwindow mode all the time, but I've obviously trained myself 
not to see any of these artefacts, so that's for pointing them out :-)

--
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/