* bug#2530: NextStep port is in bad shape
[not found] <005B7935-3DF1-4827-A507-6F83D8615626@digg.com>
@ 2009-05-04 21:58 ` David Reitter
0 siblings, 0 replies; only message in thread
From: David Reitter @ 2009-05-04 21:58 UTC (permalink / raw)
To: Ian Eure; +Cc: 2530, Emacs-Devel devel
[-- 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 --]
^ permalink raw reply [flat|nested] only message in thread