Re: macOS metal rendering engine in mac port

[Alan Third <alan@idiocy.org>]

On Fri, May 21, 2021 at 08:27:14AM -0700, Aaron Jensen wrote:
> 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).

Thanks for this.

> 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

That is quite a dramatic difference!

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

I believe this is why it's no longer the default. All the shouting was
when it was disabled and people didn't read the note and thought it
was new.

> How do you typically measure framerate?

With this code that I nabbed from in here:

     (defun scroll-up-benchmark ()
       (interactive)
       (let ((oldgc gcs-done)
             (oldtime (float-time)))
         (condition-case nil (while t (scroll-up) (redisplay))
           (error (message "GCs: %d Elapsed time: %f seconds"
                           (- gcs-done oldgc) (- (float-time) oldtime))))))

> 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)

This is quite interesting! It looks like metal reduces the total
throughput, but speeds up the time it take to actually get the image
to the screen. I wonder why that is...?

> > 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?

Yes, and I don't think you need to do anything special with
optimisation levels.

Load instruments.app, choose "time profiler", then at the top select
emacs and hit the record button. Do whatever you do, then hit the stop
button, and the window below should give some indication of where it
is spending the most time. I was thinking that it would be in the copy
from one surface to the other, but I profiled my own build and it
appears to be negligible. OTOH, since your surfaces are much bigger
that might be it.

I've tried reducing the amount of times the NS port updates the
screen, although I don't think I've really been very successful, but
you may as well give it a go and see if it makes any difference.
Please try the scratch/ns/surface-stuff branch.

And for a laugh try this patch on top of that branch. It's not
suitable for general use, but it seems a bit faster here.

modified   src/nsterm.m
@@ -8516,6 +8516,7 @@ - (void)updateLayer
      could use to force it, but we shouldn't often get the same
      surface twice in a row.  */
   [[self layer] setContents:(id)[surface getSurface]];
+  [[self layer] setContentsChanged];
 }
 #endif
 
@@ -9716,7 +9717,7 @@ @implementation EmacsSurface
    probably be some sort of pruning job that removes excess
    surfaces.  */
 
-#define CACHE_MAX_SIZE 2
+#define CACHE_MAX_SIZE 1
 
 - (id) initWithSize: (NSSize)s
          ColorSpace: (CGColorSpaceRef)cs

If that doesn't help with the lag then I think I've only got one other
thing to try before trying to implement 3D rendering. ;)
-- 
Alan Third