removing flickering in emacs

removing flickering in emacs

[Michal Maruška]

Hello,
I have written a patch for CVS emacs as a proof-of-concept for my method of
removing flickering caused by using background (pixel or pixmap) of windows in
X11, flickering which happens on Exposure, and on resizing.

The method is described at

   http://maruska.dyndns.org/wiki/anti-flicker-method

I don't know Xt, so I limit myself to xlib, and I tested the patch with 
./configure  --with-x-toolkit=no --without-gtk  (--with-png --with-jpeg --without-xim)


I would appreciate comments from people who know the display code.


The patch itself is:
http://maruska.dyndns.org/comp/packages/cvs-emacs-flicker-free.patch

thank you.

Re: removing flickering in emacs

[Jan D.]

Michal Maruška wrote:

>Hello,
>I have written a patch for CVS emacs as a proof-of-concept for my method of
>removing flickering caused by using background (pixel or pixmap) of windows in
>X11, flickering which happens on Exposure, and on resizing.
>
>The method is described at
>
>   http://maruska.dyndns.org/wiki/anti-flicker-method
>
>I don't know Xt, so I limit myself to xlib, and I tested the patch with 
>./configure  --with-x-toolkit=no --without-gtk  (--with-png --with-jpeg --without-xim)
>
>
>I would appreciate comments from people who know the display code.
>
>
>The patch itself is:
>http://maruska.dyndns.org/comp/packages/cvs-emacs-flicker-free.patch
>


I find the patch hard to follow, there are too much #if 0 and code that 
is commented out. But reading your anti-flicker-method page it seem that 
the theory is to use window background None and explicitly write the 
background yourself. 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.

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

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?

Jan D.

Re: removing flickering in emacs

[gerd.moellmann]

> You wonder about Gtk+ on you page. IMHO they have taken the proper
> approach to flikering by using double buffering everywhere.

Just a side note: I remember having experimented with double-buffering
in Emacs.  IIRC, it worked, but--at that time--, gave no advantage
compared to drawing directly to the screen.  (Which might have changed
once more complex screen updates were done.)  Perhaps that code still
lives in some CVS branch.

Re: removing flickering in emacs

[Jan D.]

gerd.moellmann@t-online.de wrote:

>>You wonder about Gtk+ on you page. IMHO they have taken the proper
>>approach to flikering by using double buffering everywhere.
>>    
>>
>
>Just a side note: I remember having experimented with double-buffering
>in Emacs.  IIRC, it worked, but--at that time--, gave no advantage
>compared to drawing directly to the screen.  (Which might have changed
>once more complex screen updates were done.)  Perhaps that code still
>lives in some CVS branch.
>  
>

I would imagine that for pure text double buffering would not give much 
to Emacs, as Emacs handles redraw very good on its own.  But maybe if 
there are images and other non-text elements in there.  Just speculating.

    Jan D.

Re: removing flickering in emacs

[Michal Maruška]

"Jan D." <jan.h.d-j7nLG5G4Q1HLoDKTGw+V6w@public.gmane.org> 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.

Re: removing flickering in emacs

[Michal Maruška]

"Jan D." <jan.h.d-j7nLG5G4Q1HLoDKTGw+V6w@public.gmane.org> writes:

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

Maybe you didn't skip from my anti-flicker-method page to the linked:
http://maruska.dyndns.org/wiki/flicker  which does contain the test cases ?

>
> Jan D.

Re: removing flickering in emacs

[Jan Djärv]

Michal Maruška wrote:
> 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.

I don't use a window manager that shows context while resizing, so I haven't 
given this any thought.  Emacs does seem to do a lot of clear area, that might 
be a bug.  Since XDrawImageString is used anyway, some clear area calls could 
possibly be removed.  However, I don't see this as such a big problem that 
requires such a big change as your apporach is.

And besides, when Emacs starts to use anti-aliased fonts, we can't use 
XDrawImage string anyway, so those clear areas might come back.

	Jan D.