From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: mmc-LfS3NqDYFGaZ9vWoFJJngh2eb7JE58TQ@public.gmane.org (Michal =?iso-8859-2?q?Maru=B9ka?=) Newsgroups: gmane.emacs.devel Subject: Re: removing flickering in emacs Date: Mon, 12 Dec 2005 16:26:34 +0100 Message-ID: References: <439D5362.3050303@swipnet.se> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1134417304 1548 80.91.229.2 (12 Dec 2005 19:55:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 12 Dec 2005 19:55:04 +0000 (UTC) Cc: emacs-devel-mXXj517/zsQ@public.gmane.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org-mXXj517/zsQ@public.gmane.org Mon Dec 12 20:54:59 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Eltif-0003mr-VF for ged-emacs-devel@m.gmane.org; Mon, 12 Dec 2005 20:52:22 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EltjA-0000ct-Oa for ged-emacs-devel@m.gmane.org; Mon, 12 Dec 2005 14:52:52 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ElqB8-0000Sp-0b for emacs-devel-mXXj517/zsQ@public.gmane.org; Mon, 12 Dec 2005 11:05:31 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Elpt3-0004Ns-Sc for emacs-devel-mXXj517/zsQ@public.gmane.org; Mon, 12 Dec 2005 10:46:50 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Elpa1-0007WD-LB for emacs-devel-mXXj517/zsQ@public.gmane.org; Mon, 12 Dec 2005 10:27:10 -0500 Original-Received: from [83.103.88.29] (helo=maruska.gotadns.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Elpbl-0000dp-4X for emacs-devel-mXXj517/zsQ@public.gmane.org; Mon, 12 Dec 2005 10:28:57 -0500 Original-Received: from linux11.maruska.tin.it.maruska.dyndns.org (linux11.maruska.tin.it [192.168.2.11]) by maruska.gotadns.org (Postfix) with ESMTP id 3DC5110A4E28C; Mon, 12 Dec 2005 16:26:37 +0100 (CET) Original-To: "Jan D." X-Archive: encrypt In-Reply-To: <439D5362.3050303-j7nLG5G4Q1HLoDKTGw+V6w@public.gmane.org> (Jan D.'s message of "Mon, 12 Dec 2005 11:39:30 +0100") User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/22.0.50 (gnu/linux) X-BeenThere: emacs-devel-mXXj517/zsQ@public.gmane.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org-mXXj517/zsQ@public.gmane.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org-mXXj517/zsQ@public.gmane.org Xref: news.gmane.org gmane.emacs.devel:47552 Archived-At: "Jan D." writes: > I find the patch hard to follow, there are too much #if 0 and code that is > commented out. I'm sorry, i have not made further cleaning to the patch since then. Please build it & see. The code compiled w/ cvs on 3 Dec. Dunno now. In all my life I looked at the emacs (display) sources for only 3 days, in which I applied the method at it. So it was (as explained in the method description) a hunt for "what else is not covered by the glyph matrix": spaces between emacs windows & frame border etc. I kept rebuilding emacs-from-cvs for a week (while still using 21.x), then finally fixed all my 21.x elisp to the 22.x api, and switched to use only my patched cvs from november. There are still little problems: *sometimes* 1-pixel-wide stripes along the frame border are not cleared etc. I have other urgent tasks, though. > But reading your anti-flicker-method page it seem that the theory > is to use window background None and explicitly write the background yourself. Exactly. > I can not see how that would improve things, instead of having the X server clear > the background itself, you are doing it from the client. This introduces more > client to server calls and no visible advantage. Let me explain, once again, the visible advantage: Definition: by "switching of 2 X windows" i mean: changing the stacking order of 2 windows, one above the other so that after "switching" the other is above the first one. Fact 1: on window switching, X server fills *implicitely* the newly unobscured area with the windown's background color. Fact 2: On resizing Emacs' X window, Emacs either explicitely calls XClearWindow, or has such Xgravity so that X server clears it implicitely, I think the former happens. What happens when X server clears either implicitely or explicitely depends on the speed of the system, but I _assume_ that this unfortunate sequence happens: 1/ Video card refreshes the screen, you see the upper window before "switching windows". 2/ X server fills area with the background and sends Expose events. 3/ Video card refreshes the screen: user is exposed to the background color ------------------------------- 4/ application pushes new content to X server and X server draws 5/ video card refreshes the screen: user finally sees the foreground. If people have systems that 2/ and 4/ are not interleaved/interposed by step 3/, then ok for them. Mine is not so fast (1700xp + matrox g450). By combining steps 2/ and 4/ (I fill background explicitely, piecewise), I avoid useless, short-time flashes of the background color over other contents. The more area is covered by "non-backtround", the more annoying is such flash. You may see it by resizing emacs X window, or perhaps by switching between 2 (emacs') X windows. As a curiosity, unicode-rxvt project removed flickering on resizing, but not on the switching of 2 X windows (my patch for original rxvt does both). Emacs display seems complicated, there seem to be a lot of places where reusing of rendered glyph-matrix is avoided(forbidden), so even with my patches applied, the unchanged text is still redrawn. I.e. If I add a line at the bottom (enlarge the X window), the text in all the emacs windows of that frame is nre-rendered. This causes a micro flicker, bearable, but would be nice to remove (for the sake of speed/cpu usage), I wanted to receive comments on this issue, from the "emacs-display people". > You wonder about Gtk+ on you page. IMHO they have taken the proper approach to > flikering by using double buffering everywhere. Unfortunately Emacs compiled for Just FYI, a nice gtk program (has nice, fast zoom) is eog (eye-of-gnome), does NOT use double-buffering: quote from the sources: /* We don't want to be double-buffered as we are SuperSmart(tm) */ > GTK can not use this feature, except for menus, scrollbars and toolbars. But as > a principle, double buffering is easier to implement (no need to keep track of > intersecting areas) and is sure to remove flicker. I claim that such double-buffering is orthogonal to what I promote. I.e. it does not solve my problem at all. For example: make a X window W1 with GtkImage inside, have a theme which has defaults background color C1, Cover the window W1 by another X window W2 full of color C2. Make it so that there is a hight contrast between C1 & C2. Now, switch the 2 windows: bring W1 above W2: you *will* see the rectangle of the GtkImage filled by color C1 (a quick flash) only to be overwritten by the pixel of the image (i suppose the image is different from constant C1). ... very annoying. Another test to see the poor gtk is by opening 2 grids of Gnumeric and switching between those 2 X Windows. It will seems as if the grid was volatile wrt. the background color. On the other hand, it was a gtk+ person, who encouraged me (see "1 Jun 2005: Goodbye flash" item on Vektor's http://vektor.ca/eclipse/blog/) --- Gtk+ probably has code to use bg None trick on menus. I simply want to use it for everything, as I switch between windows very often. > As a side not, I haven't seen much flicker in Emacs, and the time that there > where some, those places where bugs that has been fixed. Can you supply a test > case where flickering in Emacs can be clearly seen? Resizing. I have a command in my Window Manager (sawfish) which adds/removes a "row" to a X window. If i run, maybe a couple of them in sequence, I get a beating in my eyes. So, I am now relieved, when i resize windows ---I can read while resizing. And I *believe* (that's just a *belief*), that switching between windows (emacs,rxvt, & others) a hundred of times a day, without the little flash is less tiring my eyes. As a final note, I would mention 2 related problems: * smooth scrolling: to be able to continue reading while you scroll, it is much better to scroll by more little steps: less than 1 text line a time, just a couple of pixels. I start to have some code for rxvt to do it (for when I scroll a text web browser elinks). Emacs would be nice too. * window switching (w/ current window managers) versus keyboard input, (not related with emacs, sorry): switching between 2 windows, in presence of a big amount of other X windows, might take time, especially when combined with "virtual desktop" (mabye called workspace) switching. If the (type-ahead) keyboard input is not guaranteed to end delivered to the newly focused window, user has to pause & somehow check.n This is another situation, where I *believe* that hundreds of such micro-checks a day do tire. I have described the problem at http://maruska.dyndns.org/wiki/sawfish-key-events and fixed such problem in my fork of Sawfish WM. > Jan D.