bug#2530: NextStep port is in bad shape

bug#2530: NextStep port is in bad shape

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

Hi Ian,

On May 4, 2009, at 4:06 PM, Ian Eure wrote:
> The main issue is performance. It's _really_ slow. In particular,  
> using Flyspell makes it really horrible to use (#2056). There also  
> seem to be problems with slow redrawing. If you highlight a URL in  
> ERC with the mouse, then move point across it, you can see it lag  
> and redraw the entire highlighted region. Drawing a highlight over a  
> multi-line area is so slow that you can watch it draw.
>
> In general, it just doesn't feel like it's ready for a stable  
> release. Are these issues known and is someone working on them?

Yes, the issue has been known for a long time.

http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=2530

To reproduce:

Emacs -Q
type:  load-history
C-j
move mouse cursor over output.

The last message about this come from Adrian Roberts, on Apr 23:

>> On Apr 20, 2009, at 11:46 PM, David Reitter wrote:
>
>> 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?


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]