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

Previous Next

Package: emacs;

Reported by: David Reitter <david.reitter <at> gmail.com>

Date: Sun, 1 Mar 2009 22:40:04 UTC

Severity: normal

Tags: unreproducible

Done: Andrew Hyatt <ahyatt <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
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: bug#2530: 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  
>>>>>> <adrian.b.robert <at> 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.





This bug report was last modified 9 years and 187 days ago.

Previous Next


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