emacs-devel
[Top][All Lists]
Advanced

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

Re: Emacs and Gnome Canvas


From: Eli Zaretskii
Subject: Re: Emacs and Gnome Canvas
Date: Fri, 16 Jul 2010 12:52:12 +0300

> Date: Fri, 16 Jul 2010 09:33:16 +0200
> From: Jan Djärv <address@hidden>
> Cc: Chong Yidong <address@hidden>, address@hidden,
>     Óscar Fuentes <address@hidden>
> 
> >    2. Restrict the actual drawings to those in response to exposure
> >       events.  This is the standard way in GTK+ and Cocoa.  That would
> >       make double-buffering straightforward in GTK+ builds.
> 
> This is good, but can the current redisplay engine really update just a part 
> of the display area?

It depends on what you mean by "redisplay engine" in this context.
The high-level, platform-independent part of the display engine has
its own ideas regarding which parts need to be redrawn, and I won't
recommend modifying that.  But this part of the engine does not draw
anything.  It just produces an interim _representation_ of the desired
screen contents, stored as a "glyph matrix" structure.  It is then the
job of the terminal-specific back-end to actually draw the screen
based on the desired matrix.  What the back-end does is entirely up to
it, provided that it keeps a very simple contract: that after it's
done, the contents of the screen is 100% according to the desired
matrix.

Btw, I don't think I understand what Mitsuharu says in this Item #2.
Surely, we cannot "restrict the actual drawings to those in response
to exposure events"?  A completely exposed window does need to be
redrawn if the buffer text changes, right?  What am I missing?




reply via email to

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