Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 16 Apr 2013 09:20:15 -0400, Stefan Monnier <address@hidden> said:

>> That shows a typical reason why recent toolkits treat the "expose"
>> handler as the primary drawing method.  By freshly redrawing
>> invalidated area in a rear-to-front way, it can provide some fancy
>> appearances such as overlapped/translucent widgets in a correct way.

> So IIUC, the "new normal" way you describe goes something like:
> - redisplay builds glyph matrices from Lisp data and invalidates the
>   parts of the display that might need to be redrawn but does not draw.
> - expose handlers use the glyph matrices to draw on the screen
>   when/where needed.
> That makes a lot of sense.

Yes.  See also this post:

  http://lists.gnu.org/archive/html/emacs-devel/2010-07/msg00821.html

(copied to the end of this mail.)

Currently, I don't think it is practical to prohibit the actual
drawing in redisplay time completely, at least in a short term, mainly
because of the item 4 in the above post.  But it makes sense to make
expose_frame more efficient (and correct).

                                     YAMAMOTO Mitsuharu
                                address@hidden

>>>>> On Thu, 15 Jul 2010 12:00:05 -0400, Chong Yidong <address@hidden> said:

> A more promising route is the one that Yamamoto Mitsuharu has
> explored, mentioned earlier in this thread, which (IIUC) treats
> Cairo as a graphical terminal to render onto, on the same footing as
> the tty/X/Windows/NS terminals.  Here, I can see a reasonable path
> to real improvement.  For example, it might allow us to use the GTK
> printing infrastructure, which operates on Cairo contexts.  If you
> are interested in redisplay development, that is the direction I'd
> suggest looking into.

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.
  3. Make expose_window etc. more efficient.  For example, the
     foreground of same row might currently be redrawn three times for
     some cases in order to handle overlaps between rows with minimal
     flickering.  This can be eliminated if double-buffering is
     introduced and whole the background is drawn at once and then
     whole the foreground is drawn afterwards.
  4. Scrolling in redisplay (x_shift_glyphs_for_insert and
     x_scroll_run) might require special treatment because copied area
     might be marked dirty at the time of scrolling.