emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: macOS metal rendering engine in mac port


From: Aaron Jensen
Subject: Re: macOS metal rendering engine in mac port
Date: Fri, 21 May 2021 08:27:14 -0700

On Fri, May 21, 2021 at 12:35 AM Alan Third <alan@idiocy.org> wrote:
>
> Out of interest, is it the metal renderer making the difference, or is
> the Mac port just better anyway?
>
> I only ask because on my Mac enabling metal rendering results in a
> *much* lower frame rate (although whether that equates to higher input
> lag I don't know).

Pressing and holding a key for 10s with a high key repeat rate:

Large frame:

NS: 300 letters input
Macport: 530 letters input
Macport with metal: 515 letters input

Smaller frame:

NS: 583 letters input
Macport: 599 letters input
Macport with metal: 595 letters input



Scrolling one line at a time with a high key repeat rate:

Large frame:

NS: 187 lines scrolled
Macport: 248 lines scrolled
Macport with metal: 171 lines scrolled

Smaller frame:

NS: 399 lines scrolled
Macport: 456 lines scrolled
Macport with meta: 338 lines scrolled

So yes, it appears that the macport without metal is actually faster
on my machine which is surprising.

How do you typically measure framerate?

That said, I have an app on my phone called "Is it snappy" that uses
the high speed camera to attempt to measure input latency. With my
full config measuring the input latency I get:

Large frame:

NS: 95.8 100.0 107.9 (101.2 ms avg)
Macport: 100.0 95.4 95.8 (97.1 ms avg)
Macport with Metal: 78.7 87.5 99.6 (88.6 ms avg)

Smaller frame (only one trial of each of these):

NS: 82.9 ms
Macport: 87.5 ms
Metal: 70.8 ms

>
> > I'm curious if now might be a good time to consider bringing over at least
> > this rendering engine from the mac port and making it a part of Emacs
> > proper. I'm not familiar with all of the reasons for keeping the mac port
> > separate so maybe this whole thing is a non-starter, but I wanted to raise
> > it because it's a real quality of life improvement on larger/higher dpi
> > screens.
>
> At that level the two ports don't really look alike, so it's not like
> it's just a case of copying the relevant code over.
>
> What might be helpful is to profile to find out what's slowing the NS
> port down.

Can I profile with XCode? What debug optimization level do I have to
use to make it useful?

Aaron



reply via email to

[Prev in Thread] Current Thread [Next in Thread]