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


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

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: David Reitter <david.reitter <at> gmail.com>
Cc: 2530 <at> debbugs.gnu.org, Emacs-Devel devel <emacs-devel <at> gnu.org>
Subject: Re: 23/NS: redraws according to mouse-face are slow
Date: Fri, 24 Apr 2009 09:12:46 +0545
On Apr 20, 2009, at 11:46 PM, David Reitter wrote:

> On Mar 4, 2009, at 4:29 PM, Adrian Robert wrote:
>
>>> I find that the redisplay of overlays that happens when the mouse is
>>> moved into an overlay with a mouse-face property are much slower in
>>> Emacs 23 (NS, under Cocoa/OS X).  It is pretty much a nasty  
>>> animation
>>> - every layer is redrawn from left to right, it seems, and every  
>>> step
>>> is visible.  It seems that background is drawn first, and then the
>>> text over it.
>>
>> Yes, this has been an issue for years from Emacs on Aqua on and it  
>> completely baffles me.  The NS code for handling mouse face is  
>> identical to other platforms as far as I can tell, so I don't know  
>> why the issue occurs only here.  And the animation is far slower  
>> than any code on the NS side could be taking.  It must be a bug  
>> somewhere on the core display side that is exposed because  
>> (guessing here) the event loop under NS is done slightly differently.
>
> Does anyone have an idea how to fix issue 2530?  I think this  
> slowness is quite painful.  In my case, it is the tabbar.el variant  
> that I'm using that causes this - I'm using several overlays (for a  
> tab-close button, for instance) that get redrawn one by one.  I  
> would imagine that this will annoy users in other use cases as well.

Or to ask it another way, is there any reason anyone can think of  
that redisplay would force calls through the x_draw_glyph_string  
pathway once for every character when overlays are present?





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.