Re: Emacs and Gnome Canvas

[YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>]

>>>>> On Fri, 16 Jul 2010 09:33:16 +0200, Jan Djärv <jan.h.d@swipnet.se> said:

>> 1. Don't draw during redisplay, but mark the updated area dirty so
>> the upcoming exposure event can trigger the actual redraw for the
>> area to be updated.

> If some characters change attribute for example foreground color,
> you have to draw it, there will be no expose.

Whenever you need drawing outside exposure events, it should be
replaced with addition of the dirty area.

>> 2. Restrict the actual drawings to those in response to exposure
>> events.  This is the standard way in GTK+ and Cocoa.  That would
>> make double-buffering straightforward in GTK+ builds.

> This is good, but can the current redisplay engine really update
> just a part of the display area?  Maybe we can set clipping to the
> expose area? 

Cocoa automatically does that.  I'm not sure about others.

> But most redrawings are not because of expose events, but of buffer
> changes, so I don't know if this would be such a big improvement.
> If you have double buffering, then you can just copy over the buffer
> when expose happens.

I've tried some double buffering in the cairo port (not in the posted
patch) by allocating completely transparent image surface with alpha
channel when we switch from Xlib drawing to cairo, and coping it when
we have to switch back.  The performance was not so satisfactory,
maybe because of alpha blending overhead.

Some documents might be useful to see why this model is recommended in
many toolkits.

Cocoa Fundamental Guide - The Core Application Architecture on Mac OS X - How Views Get Drawn
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaFundamentals/CoreAppArchitecture/CoreAppArchitecture.html#//apple_ref/doc/uid/TP40002974-CH8-SW18

The GTK+ Drawing Model
http://library.gnome.org/devel/gtk/stable/chap-drawing-model.html

Some inefficiency specific to the cairo port comes from repeated
acquisition/release of Xlib surface during redisplay.  This can be
simplified if drawing is restricted to exposure.

>> 3. Make expose_window etc. more efficient.  For example, the
>> foreground of same row might currently be redrawn three times for
>> some cases in order to handle overlaps between rows with minimal
>> flickering.  This can be eliminated if double-buffering is
>> introduced and whole the background is drawn at once and then whole
>> the foreground is drawn afterwards.

> Are there many of these "reduce flicker" drawings going on?

It depends on the fonts used.

> Double buffer would be nice, I think it could help with images also
> (now images are drawn to a pixmap first, then copied to the frame).

Yes.  Many of such code can simplified.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp