emacs-devel
[Top][All Lists]
Advanced

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

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


From: Adrian Robert
Subject: Re: 23/NS: redraws according to mouse-face are slow
Date: Wed, 6 May 2009 08:55:36 +0700


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

On Tue, 5 May 2009 17:36:31 +0700, Adrian Robert <address@hidden> 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.





reply via email to

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