[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs Mac port
From: |
Jan Djärv |
Subject: |
Re: Emacs Mac port |
Date: |
Wed, 17 Apr 2013 08:36:25 +0200 |
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.
- Re: Emacs Mac port, (continued)
- Re: Emacs Mac port, YAMAMOTO Mitsuharu, 2013/04/15
- Re: Emacs Mac port, YAMAMOTO Mitsuharu, 2013/04/15
- Re: Emacs Mac port, Eli Zaretskii, 2013/04/16
- Re: Emacs Mac port, YAMAMOTO Mitsuharu, 2013/04/16
- Re: Emacs Mac port, YAMAMOTO Mitsuharu, 2013/04/16
- Re: Emacs Mac port, Stefan Monnier, 2013/04/16
- Re: Emacs Mac port, Eli Zaretskii, 2013/04/16
- Re: Emacs Mac port, YAMAMOTO Mitsuharu, 2013/04/16
- Re: Emacs Mac port, Jan Djärv, 2013/04/17
- Re: Emacs Mac port, YAMAMOTO Mitsuharu, 2013/04/17
- Re: Emacs Mac port,
Jan Djärv <=
- Re: Emacs Mac port, YAMAMOTO Mitsuharu, 2013/04/18
- Re: Emacs Mac port, Jan Djärv, 2013/04/19
- Re: Emacs Mac port, Nix, 2013/04/22
- Re: Emacs Mac port, YAMAMOTO Mitsuharu, 2013/04/22
- Re: Emacs Mac port, YAMAMOTO Mitsuharu, 2013/04/16