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/