Re: Emacs and Gnome Canvas

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 17 Jul 2010 10:00:40 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: jan.h.d@swipnet.se,
> 	ofv@wanadoo.es,
> 	cyd@stupidchicken.com,
> 	emacs-devel@gnu.org
> 
> >> It also reuses functions primarily designed for drawing during
> >> redisplay and that does not necessarily efficient for exposure
> >> handing.
> 
> > Are you talking about draw_glyphs?  If so, how is it biased in favor
> > of redisplay, and what would be a more efficient way of drawing
> > glyphs in a specified area of the display than what draw_glyphs
> > does?
> 
> As I mentioned, row overlapping is handled in rather an inefficient
> way (by calling draw_glyphs for three times if the row is overlapping
> and overlapped).  With double-buffering, we can draw whole the
> background of the specified area (possibly containing multiple rows)
> at once and then draw the whole foreground afterwards.

Someone should profile the current redisplay and see which part(s) of
it take most of the processing time.  Without such a profile, we are
making the classic mistake of optimizing in a wrong place.

FWIW, Gerd Möllman once told me that the most computationally
intensive place is in face merging and realization, which is not run
at all when expose events are processed.  I don't know if it's true
nowadays, but it's well known that guessing where the hot spots are is
a very bad idea, because the guesses are usually plain wrong, more so
if the guessing parties didn't write the code.