GNU bug report logs - #2530
23/NS: redraws according to mouse-face are slow

Previous Next

Full log

Message #77 received at 2530 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: David Reitter <david.reitter <at> gmail.com>, 2530 <at> debbugs.gnu.org,
        Chong Yidong <cyd <at> stupidchicken.com>,
        Emacs-Devel devel <emacs-devel <at> gnu.org>
Subject: Re: 23/NS: redraws according to mouse-face are slow
Date: Wed, 06 May 2009 11:25:35 +0900

>>>>> On Wed, 6 May 2009 08:55:36 +0700, Adrian Robert <adrian.b.robert <at> gmail.com> said:

>> The effect of ns_update_begin seems to avoid -[NSWindow
>> flushWindow] call (via ns_unfocus) for each ns_draw_glyph_string
>> call.  Does this frequent flushing necessary in the first place?
>> Other terms don't seem to do flushing for each string drawing call.

> My assumption was that it is legal to call draw_glyph_string()
> outside of an update_begin()-end() pair.  So draw_glyph_string()
> must be able to operate in "self-contained" mode, which and the
> flush is needed.  The same logic holds for other RIF functions --
> that they can either be called in one-shot mode or in batch mode
> (inside update begin-end).  In the latter case, focus/unfocus
> reflect the batching by holding screen flush until end.

Other terms don't do flushing even at update_end, let alone at the end
of each one-shot drawing operation (you may see XFlush calls in the
code but they are mostly defined as no-ops).  IIUC, flushing happens
only by explicit flush_display(_optional) RIF calls or at the timing
of polling/receiving window system events (e.g., XPending on X11, and
ReceiveNextEvent on Carbon) implicitly.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.