Re: X / gtk-x11 / flicker and other problems
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 so 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/
Re: X / gtk-x11 / flicker and other problems
- 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:- 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. 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. I'm guessing from this that you are using -multiwindow mode. [ ... ] 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. Oh - please explain a bit more I'm not aware of being in any particular mode but if there are different modes I could try, I'd be happy to experiment if you'll tell me how to set them up. 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). 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... I think I'd agree with that. It's nit-picking I know, but IMHO gtk-win32 (which resizes continuously) gives a more satisfying and somehow a "more professional" experience. Do please let me know if I can try out some alternative modes. John -- 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/
Re: X / gtk-x11 / flicker and other problems
May I say in its defence (after a bit more experimenting) that when comparing Cygwin-X/gtk-x11 against gtk-win32, X's text handling is noticeably superior at high resolutions (at least, on my system). With my monitor set to 1600x1200, Cygwin-X's text is still crisp and clear - whereas gtk-win32's looks decidedly fuzzy. Anyway, I wanted to try working in 'rooted' mode to see if this would improve the flickering that I reported yesterday. Normally I start X just by running the batch file startxwin.bat. Looking in that file I can see that the command to start X is:- %RUN% XWin -multiwindow -multiplemonitors -clipboard -silent-dup-error Perhaps naively I figure that if I changed it to this:- %RUN% XWin -clipboard -silent-dup-error I'd get a single monitor in the 'rooted' mode that John referred to yesterday (i.e. able to use DirectDraw). However, there seems to be more to it than that. The above line causes xserver to run in a very flickery window, as if something isn't set up properly. What do I need to do to see the DirectDraw feature in action? John -- 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/
Re: X / gtk-x11 / flicker and other problems
"John Emmas" writes: >monitor set to 1600x1200, Cygwin-X's text is still crisp and clear - whereas >gtk-win32's looks decidedly fuzzy. Cygwin-X uses bit-mapped fonts, with only black and white pixels, perhaps gtk-win32 uses some form of antialiasing? -- Fredrik Stax\"ang | rot13: s...@hcqngr.hh.fr This is all you need to know about vi: ESC : q ! RET -- 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/
Re: X / gtk-x11 / flicker and other problems
- Original Message - From: "Jon TURNEY" Subject: Re: X / gtk-x11 / flicker and other problems 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. Jon - did I understand you correctly here? Are you saying that there's an alternative mode I could try that should give me better performance (even though it might be limited to just one monitor)? If so, how do I need to call Xwin to work in a rooted mode? Thanks, John -- 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/
Re: X / gtk-x11 / flicker and other problems [+PATCH]
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 +
+++ xorg-server-1.5.3/xserver/hw/xwin/winmultiwindowwndproc.c 2009-02-11
14:11:31.34375 +
@@ -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.65625 +
+++ xorg-server-1.5.3/xserver/hw/xwin/winwin32rootlesswndproc.c 2009-02-10
21:55:56.59375 +
@@ -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/
Re: X / gtk-x11 / flicker and other problems [+PATCH]
- Original Message - From: "Jon TURNEY" Subject: Re: X / gtk-x11 / flicker and other problems [+PATCH] Bah! Now I've noticed the flickering again, so I have to fix it. Your cunning plan worked. :-) Thanks very much for that, Jon. I'll apply your patch at the weekend (presumably it'll work with x11r6, which I'm still on?) My only qualm is that I'm not very experienced with building Cygwin stuff from source. Mostly, I've tried the "configure" and "make" route which has so far been a bit hit-and-miss. Should I be using cygport to do the rebuild and if so, what command(s) should I need? John -- 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/
Re: X / gtk-x11 / flicker and other problems [+PATCH]
Oh BTW, I should have added:- One particular problem is that the xserver will only support twin monitors if they both have the same settings (resolution etc). Hmm... I thought this worked. The only restriction should be that the colour-depth of the monitors is the same... Sorry, I stand corrected. I hadn't realised that I only needed to match the colour depths, so for months I've been matching the resolutions too. After a bit of experimenting this morning I now realise that it wasn't necessary. Apologies. John -- 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/
Re: X / gtk-x11 / flicker and other problems [+PATCH]
Jon - I just realised that I don't seem to have the source for X11 (which is presumably what I need before applying your patch). I've looked on my usual Cygwin mirror (ftp://mirrors.xmission.com) as well as looking in Cygwin-Ports (ftp://sourceware.org) but I couldn't see what I needed to download. Should I have found the source code on one of the mirrors? Thanks, John -- 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/
Re: X / gtk-x11 / flicker and other problems [+PATCH]
John Emmas wrote: Jon - I just realised that I don't seem to have the source for X11 (which is presumably what I need before applying your patch). I've looked on my usual Cygwin mirror (ftp://mirrors.xmission.com) as well as looking in Cygwin-Ports (ftp://sourceware.org) but I couldn't see what I needed to download. Should I have found the source code on one of the mirrors? Are you downloading the source with 'setup.exe'? If not, run it and select the 'Src?' box. You may be to re-install the package(s) in order to see this box (assuming you already have the current version.) -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 429-6305 - FAX Holliston, MA 01746 -- 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/
Re: X / gtk-x11 / flicker and other problems [+PATCH]
Thanks Jon & Larry, I can see a package called "libX11 : X.OrgX11 core library (source)". Will that bring in all the source files I need or is there a bit more to it than that? John -- 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/
Re: X / gtk-x11 / flicker and other problems [+PATCH]
John Emmas wrote: I can see a package called "libX11 : X.OrgX11 core library (source)". Will that bring in all the source files I need or is there a bit more to it than that? The package containing the X server is 'xorg-server'. That is the package for which you need ask setup to install the source for (by ticking the 'Src?' box) It seems the CG [1] neglects to mention this simple fact, I guess I should fix that :-) [1] http://x.cygwin.com/docs/cg/prog-obtaining-source.html -- 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/
Re: X / gtk-x11 / flicker and other problems [+PATCH]
Jon - I followed the instructions from that link and everything went well until I reached stage 4 ( ./autogen.sh -V ). At that stage I get this output:- autoreconf-2.61: Entering directory `.' autoreconf-2.61: configure.ac: not using Gettext autoreconf-2.61: running: aclocal autoreconf-2.61: configure.ac: tracing autoreconf-2.61: running: libtoolize --copy libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. autoreconf-2.61: running: /usr/bin/autoconf-2.61 configure.ac:614: error: possibly undefined macro: XTRANS_CONNECTION_FLAGS If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf-2.61: /usr/bin/autoconf-2.61 failed with exit status: 1 Any suggestions for fixing this error? Also, assuming I get through that stage and apply your patch, what do I subsequently run to build and install the xserver? Is it the usual "./configure", "make" and "make install" or something else? John -- 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/
Re: X / gtk-x11 / flicker and other problems [+PATCH]
John Emmas wrote: Jon - I followed the instructions from that link and everything went well until I reached stage 4 ( ./autogen.sh -V ). At that stage I get this output:- autoreconf-2.61: Entering directory `.' autoreconf-2.61: configure.ac: not using Gettext autoreconf-2.61: running: aclocal autoreconf-2.61: configure.ac: tracing autoreconf-2.61: running: libtoolize --copy libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. autoreconf-2.61: running: /usr/bin/autoconf-2.61 configure.ac:614: error: possibly undefined macro: XTRANS_CONNECTION_FLAGS If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf-2.61: /usr/bin/autoconf-2.61 failed with exit status: 1 Do you have the package 'xtrans' installed? The flow of the document needs correcting so that the required packages, listed on the next page, come before this section. Any suggestions for fixing this error? Also, assuming I get through that stage and apply your patch, what do I subsequently run to build and install the xserver? Is it the usual "./configure", "make" and "make install" or something else? I think the next page, http://x.cygwin.com/docs/cg/prog-build-native.html, should answer those questions :-) -- 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/
Re: X / gtk-x11 / flicker and other problems [+PATCH]
Still haven't managed to run 'configure' successfully when trying to build xorg-server from source. I'm now getting a simple error relating to GLproto:- checking for GL... configure: error: Package requirements (glproto >= 1.4.9 gl >= 7.1.0) were not met: Requested 'glproto >= 1.4.9' but version of GLProto is 1.4.8 Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables GL_CFLAGS and GL_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. 1.4.8 is the latest version according to my usual mirror. Anyone know if 1.4.9 can be obtained anywhere using setup.exe? Or how should I set those GL_ env variables to force it to use 1.4.8? Thanks, John -- 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/
Re: X / gtk-x11 / flicker and other problems [+PATCH]
John Emmas wrote: Still haven't managed to run 'configure' successfully when trying to build xorg-server from source. I'm now getting a simple error relating to GLproto:- checking for GL... configure: error: Package requirements (glproto >= 1.4.9 gl >= 7.1.0) were not met: Requested 'glproto >= 1.4.9' but version of GLProto is 1.4.8 [...] 1.4.8 is the latest version according to my usual mirror. Anyone know if 1.4.9 can be obtained anywhere using setup.exe? Or how should I set those GL_ env variables to force it to use 1.4.8? Nope, 1.4.9 is the latest (indeed, only) version in cygwin mirrors. http://cygwin.com/cgi-bin2/package-grep.cgi?grep=glproto 1.4.8 was only ever in cygwinports as far as I can tell. I suspect that the 'exciting and different' way that setup compares versions between package servers might be involved here. -- 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/
Re: X / gtk-x11 / flicker and other problems [+PATCH]
- Original Message - From: "Jon TURNEY" Nope, 1.4.9 is the latest (indeed, only) version in cygwin mirrors. http://cygwin.com/cgi-bin2/package-grep.cgi?grep=glproto 1.4.8 was only ever in cygwinports as far as I can tell. I suspect that the 'exciting and different' way that setup compares versions between package servers might be involved here. Well I ended up finding 1.4.9 in a tar.bz2 file and installed it from that. The previous test is now passing - but further on I get these errors:- No package 'videoproto' found No package 'compositeproto' found No package 'xineramaproto' found No package 'xkbfile' found I've managed to track down 'compositeproto' and 'xineramaproto' but not the others :-( John -- 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/
Re: X / gtk-x11 / flicker and other problems [+PATCH]
John Emmas wrote: - Original Message - From: "Jon TURNEY" Nope, 1.4.9 is the latest (indeed, only) version in cygwin mirrors. http://cygwin.com/cgi-bin2/package-grep.cgi?grep=glproto 1.4.8 was only ever in cygwinports as far as I can tell. I suspect that the 'exciting and different' way that setup compares versions between package servers might be involved here. Well I ended up finding 1.4.9 in a tar.bz2 file and installed it from that. The previous test is now passing - but further on I get these errors:- No package 'videoproto' found No package 'compositeproto' found No package 'xineramaproto' found No package 'xkbfile' found I've managed to track down 'compositeproto' and 'xineramaproto' but not the others :-( videoproto isn't packaged as it doesn't do anything useful for us. You need to configure with --disable-xv xkbfile is provided by libxkbfile-devel -- 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/
Re: X / gtk-x11 / flicker and other problems [+PATCH]
- Original Message - From: "Jon TURNEY" videoproto isn't packaged as it doesn't do anything useful for us. You need to configure with --disable-xv xkbfile is provided by libxkbfile-devel Okay, I fixed those problems and the build appeared to go okay, following these instructions (for a Standard build) but adding --disable-xv at the configure stage:- http://x.cygwin.com/docs/cg/prog-build-native.html I then got to the next stage which is to try running the local build. I issued this command:- hw/xwin/XWin -multiwindow -multiplemonitors -clipboard -silent-dup-error but got a message box saying "A fatal error has occured and Cygwin/X will now exit. Please open /usr/var/log/XWin %s.log for more information" However, there's no such folder on my system. I do have a folder called /var/log/ but the most recent file in it is dated about an hour ago... :-( Simply issuing 'hw/xwin/XWin' gives me the same problem. Also (this may be significant) my new XWin.exe (weighing in at just under 9Mb) is about double the size of the previous one. John -- 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/
Re: X / gtk-x11 / flicker and other problems [+PATCH]
John Emmas wrote: Okay, I fixed those problems and the build appeared to go okay, following these instructions (for a Standard build) but adding --disable-xv at the configure stage:- http://x.cygwin.com/docs/cg/prog-build-native.html I then got to the next stage which is to try running the local build. I issued this command:- hw/xwin/XWin -multiwindow -multiplemonitors -clipboard -silent-dup-error but got a message box saying "A fatal error has occured and Cygwin/X will now exit. Please open /usr/var/log/XWin %s.log for more information" However, there's no such folder on my system. I do have a folder called /var/log/ but the most recent file in it is dated about an hour ago... :-( I guess you need to either create that directory so it can write to it, or add -with-log-dir=/var/log to ./configure Alternatively, running with CYGWIN=tty will allow XWin to write to stdout successfully. Simply issuing 'hw/xwin/XWin' gives me the same problem. Also (this may be significant) my new XWin.exe (weighing in at just under 9Mb) is about double the size of the previous one. That sounds about right for an unstripped XWin.exe built with debugging symbols. -- 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/
Re: X / gtk-x11 / flicker and other problems [+PATCH]
- Original Message - From: "Jon TURNEY" Subject: Re: X / gtk-x11 / flicker and other problems [+PATCH] I guess you need to either create that directory so it can write to it Done that - but now I'm getting a bit paranoid... it fixed the original problem but now when I try to launch XWin I get a message box saying "Windows Firewall has blocked this program from accepting connections from the internet or network. If you trust the publisher you can unblock it." Hmmm... do I / should I unblock it?? Unblocking it temporarily lets me run XWin - apparently fine, although I see a couple of errors in the log file:- (EE) AIGLX error: dlopen of /usr/lib/dri/swrast_dri.so failed (No such file or directory) (EE) GLX: could not load software renderer Are these anything to be worried about? BTW Jon - flickering seems to be vastly improved!! Thanks for all your help. John -- 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/
Re: X / gtk-x11 / flicker and other problems [+PATCH]
John Emmas wrote: - Original Message - From: "Jon TURNEY" Subject: Re: X / gtk-x11 / flicker and other problems [+PATCH] I guess you need to either create that directory so it can write to it Done that - but now I'm getting a bit paranoid... it fixed the original problem but now when I try to launch XWin I get a message box saying "Windows Firewall has blocked this program from accepting connections from the internet or network. If you trust the publisher you can unblock it." Hmmm... do I / should I unblock it?? Unblocking it temporarily lets me run You'll have to make your own mind up about whether or not you trust the publisher of that program or not :-) For what it's worth, the X server needs to be able to accept connections from client programs to work, and the firewall correctly considers this XWin to be a different program to the one in /usr/bin/, which you have probably permitted to accept connections at some time in the past... XWin - apparently fine, although I see a couple of errors in the log file:- (EE) AIGLX error: dlopen of /usr/lib/dri/swrast_dri.so failed (No such file or directory) (EE) GLX: could not load software renderer Are these anything to be worried about? OpenGL X applications won't work. I don't know if that concerns you or not :-) Given your earlier problems with glproto, I suspect you don't have libGL installed properly... $ cygcheck -f /usr/lib/dri/swrast_dri.so libGL1-7.2-2 BTW Jon - flickering seems to be vastly improved!! Thanks for all your help. \o/ Thanks for being the guinea pig. I'll update the CG document to hopefully clarify the things which caused you problems. -- 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/
Re: X / gtk-x11 / flicker and other problems [+PATCH]
- Original Message - From: "Jon TURNEY" Thanks for being the guinea pig. I'll update the CG document to hopefully clarify the things which caused you problems. Thanks. One more thing Jon. I'm probably being ludicrously simplistic here - but to fix the resizing problem (not resizing until the user lets go of the mouse button) could there be a simple fix for this just by responding to the WM_MOUSEHOVER notification? For example:- 1) Check wParam to see if the left button is currently pressed. 2) If so, call Invalidate() for the window being resized. 3) Call TrackMouseEvent() on next WM_MOUSEMOVE (so that the next hover event gets notified). John -- 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/
Re: X / gtk-x11 / flicker and other problems [+PATCH]
- Original Message - From: "John Emmas" One more thing Jon. I'm probably being ludicrously simplistic here - but to fix the resizing problem (not resizing until the user lets go of the mouse button) could there be a simple fix for this just by responding to the WM_MOUSEHOVER notification? Or if you'd prefer not to do this in WM_SIZING, WM_NCMOUSEHOVER might be more successful and would at least make Cygwin's resizing work more like Linux's. I guess the main problem with WM_NCMOUSEHOVER though is that it doesn't get issued by older versions of Windows. However, that's Windows fault, not Cygwin's. John -- 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/
