bug-gnu-emacs
[Top][All Lists]
Advanced

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

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


From: YAMAMOTO Mitsuharu
Subject: bug#2530: 23/NS: redraws according to mouse-face are slow
Date: Wed, 06 May 2009 11:25:35 +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, 6 May 2009 08:55:36 +0700, Adrian Robert 
>>>>> <adrian.b.robert@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@math.s.chiba-u.ac.jp






reply via email to

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