GNU bug report logs -
#73563
[Ben Simms] Performance bottleneck in ns_draw_fringe_bitmap
Previous Next
Full log
View this message in rfc822 format
On 25/5/2025 1:10 am, Alan Third wrote:
> Since we can't really use Core Graphics code in the NS port, I've
> tried improving the bitmap tracing a little. I have my doubts it will
> improve things much, but can you please try it and see how it
> compares? I tried it here and the difference between all three
> versions of the code is within 0.2 of a second, and totally
> inconsistent. I couldn't vouch for any of them being consistently
> faster.
Your patch appears to have fixed it. I can now add 8-bit fringe bitmaps
and scroll a buffer with no noticeable slowdown. Unpatched Emacs will
slow down to a crawl, probably only redisplaying 1-3 times a second, Ben
Simms' patch looks equally as performant as this one however Ben's seems
to break with dape-mode which arranges the Emacs frame into a bunch of
windows etc. Yours, Alan, seems to not bork Emacs display under
dape-mode but there are tiny 1-pixel artifacts in the margin (only in
dape-mode). Dape-mode seems to be using Emacs' features that break when
combined with fringes as if I turn fringes off Emacs displays normally
thereafter.
I tried writing a benchmark for this (here:
https://gist.github.com/tsujp/79d743ca23555c679f5a9cb667ddc3be) but even
on the version of Emacs which was incredibly laggy the results all came
out within ~0.2 seconds of each other.
It appeared to lag the most when the margin was approaching the end of,
or start of, the top/bottom of a buffer and while it still lagged a lot
otherwise it was a tiny bit less so (it felt like).
I can provide screenshots and/or screen recordings of the lag in all 3
variants (vanilla Emacs, Ben's patch, and your patch Alan) since this
seems like quite a nasty thing to demonstrate.
/Jordan
This bug report was last modified 14 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.