Re: macOS metal rendering engine in mac port

[Alan Third]

On Sat, May 22, 2021 at 02:20:34PM -0700, Aaron Jensen wrote:
> > How can the Mac port only see a change of 0.6s while the NS port sees
> > a change of 1.3s, when the only change is turning line numbers on or
> > off? Line numbers performance should surely be mostly independent of
> > the UI toolkit?
> 
> No idea. It seems to be percentage based more than fixed for whatever
> reason. I built emacs 27 w/ -g3 -O2

Me too. I checked the Mac port flags too in case it was doing
something sneaky, but nope, looks the same.

> > You know, my benchmarking is all over the place. I literally just did
> > two runs at 11s and another two at 8.6s. Nothing changed. And I
> > regularly see a code change produce an improvement, then undoing the
> > change retaining the improvement. It's like rebuilding the exact same
> > code base produces a completely different performance result.
> >
> > I suspect my Mac rides the CPU frequency continuously or something.
> 
> Mine are fairly consistent. I imagine hitting thermal would hurt
> though and Intel macs love to do that.

Yeah, I wonder if that's what's happening. I have to say that I don't
think this Mac has ever been what I'd consider fast. My ancient first
gen i7 absolutely wipes the floor with it in compilation speed
despite being at least 7 years older. I guess Moores law really did
run out of steam. ;)

> What isn't consistent is typing experience. There are times when it's
> just like molasses but I can't necessarily reproduce that with
> benchmarks. I wonder if the separate threaded IO from the mac port
> helps make things feel more consistent in some way.

Probably, the threading also seems to be used to do the buffer copies
and things. AFAICT it also offloads the copy to Metal when it's
enabled, although I imagine that then involves copying the buffer back
down to system RAM from VRAM for updating, so I don't know how much of
a win it really is. On a fast graphics card it maybe really is a big
win.

> It'd be great to try an emacs-28 with the 27+flicker patch rendering.
> I'd be curious how that'd feel w/ native comp. Maybe that'd make
> enough of a difference for me on this screen.

It's a lot of work. I'd have to be sure that the patch actually stops
the flashing and blanking before I tried that. I'm not hopeful, tbh.

Anyway, the last thing I want to try to improve lag is to move the
buffer copy to as soon after the layer update as possible, so that
when you hit a key we don't have to wait for it before we can start
drawing. I've pushed a change to the surface-stuff branch, so can you
please give it a go and see if there's any improvement.
-- 
Alan Third