Re: removing flickering in emacs

[Michal Maruška]

"Jan D." <address@hidden> 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.