Subject: Re: bug#73563: [Ben Simms] Performance bottleneck in ns_draw_fringe_bitmap

From: Jordan Ellis Coppard <[email-masked]>
Date: Tue, 3 Jun 2025 17:25:40 +0900

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