Re: Emacs Mac port

[Jan Djärv]

Hello.

17 apr 2013 kl. 07:46 skrev YAMAMOTO Mitsuharu <address@hidden>:

>>>>>> On Wed, 17 Apr 2013 07:08:25 +0200, Jan Djärv <address@hidden> said:
> 
>> 17 apr 2013 kl. 01:52 skrev YAMAMOTO Mitsuharu <address@hidden>:
>>> 
>>> My proof-of-concept cairo port was primarily intended for the printing
>>> support, not for screen drawing (though it does both).
>>> 
>>> http://lists.gnu.org/archive/html/emacs-devel/2009-04/msg00390.html
>>> 
>>> Screen drawing in the cairo port is not so efficient for several
>>> reasons.  To make it more efficient, one would need some modest
>>> modifications to the current drawing model in Emacs.
>>> 
>>> 1. Don't draw during redisplay, but mark the updated area dirty so
>>> the upcoming exposure event can trigger the actual redraw for the
>>> area to be updated.
>>> 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.
> 
>> Double buffering in the Gtk+ is not turned off because of the expose
>> handler, but because Gtk+ can not double buffer text/images not
>> drawn with Gtk/Gdk primitives, and Emacs uses X primitives.  So
>> changing the way expose handler works does absolutely nothing to
>> make Gtk+ double buffering easier.
> 
> That would be correct in itself.  But my description above is in the
> context of cairo.  The cairo context passed via the expose handler is
> automatically double-buffered.
> 

This is not just for cairo. Gtk+ double buffers anything drawn with Gtk in the 
expose handler. For example, menus and toolbar in a Gtk Emacs are double 
buffered.

If moving things to the expose handler is considered, one must take into 
account non-Gtk X11 builds. X11 does not have a mechanism for invalidating 
regions for the purpose of generating an expose event. Gtk+ generates syntetic 
(internal) expose events.  I guess we could do the same, but it is work to be 
done by someone(tm).

I also suspect the synchronous nature of Elisp would make this complicated. For 
example, if Lisp code adds text or image to a buffer, the text or image would 
be visible to the user at some point in the future, not when the Lisp code is 
done. Unless some synchronization is added between Lisp code and the expose 
handler. 

     Jan D.