NextStep port is in bad shape

NextStep port is in bad shape

[Ian Eure]

So I've been running nightly builds from CVS HEAD for around four  
months now, and I'm alarmed to see that Emacs is getting closer to  
release, while the NextStep port is in really bad shape.

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?

  - Ian

Re: 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 --]