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?
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?