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....
Cygwin/X: Avoid a visual glitch on window move in rootless modes
Handle and ignore WM_ERASEBKGND since we repaint the entire invalidated region
anyhow
(this avoids a white flickering on window resize)
---
xserver/hw/xwin/winmultiwindowwndproc.c | 8 ++++++++
xserver/hw/xwin/winwin32rootlesswndproc.c | 11 +++++++++++
2 files changed, 19 insertions(+)
Index: xorg-server-1.5.3/xserver/hw/xwin/winmultiwindowwndproc.c
===================================================================
--- xorg-server-1.5.3.orig/xserver/hw/xwin/winmultiwindowwndproc.c
2009-02-10 21:55:54.921875000 +0000
+++ xorg-server-1.5.3/xserver/hw/xwin/winmultiwindowwndproc.c 2009-02-11
14:11:31.343750000 +0000
@@ -468,6 +468,14 @@
HandleCustomWM_INITMENU ((unsigned long)hwnd, wParam);
break;
+ case WM_ERASEBKGND:
+ /*
+ * Pretend that we did erase the background but we don't care,
+ * since we repaint the entire region anyhow
+ * This avoids some flickering when resizing.
+ */
+ return TRUE;
+
case WM_PAINT:
/* Only paint if our window handle is valid */
if (hwndScreen == NULL)
Index: xorg-server-1.5.3/xserver/hw/xwin/winwin32rootlesswndproc.c
===================================================================
--- xorg-server-1.5.3.orig/xserver/hw/xwin/winwin32rootlesswndproc.c
2009-02-10 21:55:54.656250000 +0000
+++ xorg-server-1.5.3/xserver/hw/xwin/winwin32rootlesswndproc.c 2009-02-10
21:55:56.593750000 +0000
@@ -779,6 +779,17 @@
SendMessage (hwndScreen, message, wParam, lParam);
return 0;
+ case WM_ERASEBKGND:
+#if CYGDEBUG
+ winDebug ("winMWExtWMWindowProc - WM_ERASEBKGND\n");
+#endif
+ /*
+ * Pretend that we did erase the background but we don't care,
+ * since we repaint the entire region anyhow
+ * This avoids some flickering when resizing.
+ */
+ return TRUE;
+
case WM_PAINT:
/* BeginPaint gives us an hdc that clips to the invalidated region */
--
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/