Re: Emacs and Gnome Canvas

["Jan Djärv" <jan.h.d@swipnet.se>]

Eli Zaretskii skrev 2010-07-15 12.24:
>> Date: Thu, 15 Jul 2010 11:29:29 +0200
>> From: Jan Djärv<jan.h.d@swipnet.se>
>> CC: ofv@wanadoo.es, emacs-devel@gnu.org
>>
>>> But the inserted character could be in the portion that is not
>>> displayed at all, in which case it does not "require redisplay".  Who
>>> should decide whether redisplay is necessary?  If that's Emacs, then
>>> it should know a lot about the display layout.  If its the Canvas,
>>> then it should know a lot about what portions of the buffer text are
>>> on the screen.
>>
>> You probably have your text in an CanvasItem that has a GtkTextBuffer.  When a
>> character is inserted, you insert in to the GtkTextBuffer.  The redisplay part
>> is then handeled internally between GtkTextBuffer, GnomeCanvas(Rich)TextItem
>> and GnomeCanvas.
>>
>> 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.  You wouldn't have to do 
redisplay all the time just in case something changed (like now), if you 
propagated the change the whole way when it happened.  This is a big 
difference on how Emacs works now.

>
> And what about redisplay optimizations?  For example, we now have a
> special method that updates a window if the only change is that point
> moved.  We don't care _why_ it moved -- there could be any number of
> input events that cause this.  However, _determining_ that only point
> moved is a non-trivial job, which examines about a dozen conditions on
> some internal variables and flags.  Then there's another non-trivial
> job: where on screen to move the cursor given the position of point.
>
> If the communications with the Canvas is by means of a GtkTextBuffer,
> how can these chores be done?  Won't we need to regenerate the
> GtkTextBuffer, or at least its large parts, even when the only change
> is point movement?

The communication with the Canvas is through CanvasItems (lines, text, images, 
and so on).  Only the text item uses GtkTextBuffer.  The text canvas item 
keeps track of the insertion point itself.  You would move out the whole 
cursor movement, text insertion, copy/paste, ... to the canvas item.  Move the 
lowlevel stuff handling to the Canvas components.

	Jan D.