On Tue, May 13, 2025 at 08:37:55PM +0900, Jordan Ellis Coppard wrote:
> Howdy,
> 
> 
> I've been using the following patch (bottom of this email) until my most
> recent rebuild of Emacs from master. Since the recent commit fixing stipple
> drawing the patch can be reduced to just: https://github.com/emacs-mirror/emacs/commit/7f2efe6503fdce2a4e552c14802644a05b581bc7
> (link to a diff authored by Ben Simms).
> 
> I've now noticed again extreme slowdown when fringe bitmaps are used. It
> appears to be proportional to the number of bits set in the bitmap. An
> 'empty' bitmap (all zeroes) doesn't yield any noticeable slowdown, a bitmap
> with 1 bit set yields a little, with 2 its noticeable and with all 8 bits
> set Emacs takes up to 1 second to respond to any input at all.
> 
> This has been the case since at least August of last year. I can get a
> minimal reproduction but it has happened on completely different
> configurations with the only common denominator being the NS build (on
> ARM-based macOS), and the use of fringe bitmaps.

I have no idea what's going on, but it looks from the trace like the
problem is in the transform to move it to the final position, or the
copy... Which are both odd as to my mind they should be fast
processes.

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.


-- 
Alan Third