[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#2530: NextStep port is in bad shape
From: |
David Reitter |
Subject: |
bug#2530: NextStep port is in bad shape |
Date: |
Mon, 4 May 2009 17:58:32 -0400 |
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?
smime.p7s
Description: S/MIME cryptographic signature
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#2530: NextStep port is in bad shape,
David Reitter <=