Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 17 Apr 2013 08:36:25 +0200, Jan Djärv <address@hidden> said:

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

According to the document (*), (standard) drawing seems to be
eventually done via cairo on GTK+ 3.

*: https://developer.gnome.org/gtk3/3.0/gtk-migrating-2-to-3.html#id1526151

  In GTK+ 3, the GDK drawing API (which closely mimics the X drawing
  API, which is itself modeled after PostScript) has been removed. All
  drawing in GTK+ 3 is done via cairo.

> 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).

Right.  Probably invalidated region management at the application
level is also meaningful/necessary for Cocoa, because scrolling or
pixel copying in AppKit, which will be used in x_scroll_run, does not
take account of the invalidated region managed by the framework.

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

The expose handler will be called when Emacs tries to read some input
from the window system.  If display is not updated for a long time
because of deferring, that means C-g is not handled for a long time
either.  If immediate update after redisplay is really necessary for
some cases, gdk_window_process_all_updates or something could be used
(after making sure that the current matrix is ready and clearing
f->garbaged).

                                     YAMAMOTO Mitsuharu
                                address@hidden