emacs-devel
[Top][All Lists]
Advanced

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

Re: Emacs Mac port


From: YAMAMOTO Mitsuharu
Subject: Re: Emacs Mac port
Date: Wed, 17 Apr 2013 14:46:41 +0900
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)

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

                                     YAMAMOTO Mitsuharu
                                address@hidden



reply via email to

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