Re: 23/NS: redraws according to mouse-face are slow

[Adrian Robert <adrian.b.robert@gmail.com>]

On May 6, 2009, at 7:50 AM, YAMAMOTO Mitsuharu wrote:

>>>>>> On Tue, 5 May 2009 17:36:31 +0700, Adrian Robert  
>>>>>> <adrian.b.robert@gmail.com> said:
>
>> That ns_update_begin() acheives the same effect suggests that
>> perhaps the core mouse face code should do this (through the RIF).
>> ns_draw_glyph_string() is not slow for any other operations, despite
>> the fact that it is called with the same granularity
>> (same-face-glyph- run) everywhere, likely because the
>> update_begin()/end() batching is used.
>
> 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.

Emacs core seems to batch most/all other sets of operations done at  
once as part of a single redisplay.

It may be that screen update batching is handled implicitly by the  
window system for X, so the distinction doesn't get made in the code  
there.

Some behavior in this area differs between MacOS and GNUstep (as may  
be seen, e.g., from the ifdefs in ns_[un]focus]), so any changes made  
should be tested on both platforms before committing.