[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs and Gnome Canvas

From: Jan Djärv
Subject: Re: Emacs and Gnome Canvas
Date: Thu, 15 Jul 2010 12:54:14 +0200
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv: Gecko/20100608 Thunderbird/3.1

Eli Zaretskii skrev 2010-07-15 12.24:
Date: Thu, 15 Jul 2010 11:29:29 +0200
From: Jan Djärv<address@hidden>
CC: address@hidden, address@hidden

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]