Re: Emacs and Gnome Canvas

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 15 Jul 2010 12:54:14 +0200
> From: Jan Djärv <jan.h.d@swipnet.se>
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> 
> >> As I said, it probably relies on having all text in the GtkTextBuffer.
> >
> > But GtkTextBuffer needs text with attributes, right?  Currently, we
> > compute these attributes as part of redisplay, and only for the
> > displayed portion of the text.  Using GtkTextBuffer, it seems like we
> > will need to have a part (or an equivalent) of that redisplay code,
> > which would need to recompute the attributes for _all_ of the text,
> > after each modification of buffer text?  How can this be fast enough?
> > E.g., what if I'm viewing a large log file with non-trivial
> > fontification and clickable parts?
> 
> If you need to recalculate attributes for the whole buffer because of one 
> character was inserted, then that is what you have to do.  But I don't think 
> that is the case.  You would have to compute the changes, and only that and 
> update your text buffer for the changed part.

Inserting one character moves all the attributes after it by one
character position, doesn't it?

> You wouldn't have to do redisplay all the time just in case
> something changed (like now)

?? We don't _do_ redisplay now all the time.  We _enter_ redisplay
every time Emacs is idle, but if nothing's changed, we exit it almost
immediately, after testing a bunch of flags.

> if you propagated the change the whole way when it happened.  This
> is a big difference on how Emacs works now.

The way it looks, parts of the current redisplay code will have to run
whenever there's a change, any change, to some buffer or some related
data structure.  If the parts affected by these changes are not
displayed, or become not displayed before the GTK+ idle handlers run,
propagating those changes would be a waste of CPU cycles.

So you win some and you lose some.  Not sure about the balance.
Basically, scrolling should be very fast (assuming it is done entirely
on the Canvas side), but I'm not sure if everything else won't be
significantly slower.