Re: Emacs Mac port

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

Hello.

17 apr 2013 kl. 07:46 skrev YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>:

>>>>>> On Wed, 17 Apr 2013 07:08:25 +0200, Jan Djärv <jan.h.d@swipnet.se> said:
> 
>> 17 apr 2013 kl. 01:52 skrev YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>:
>>> 
>>> 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.