Re: macOS metal rendering engine in mac port

[Alan Third]

On Sun, May 23, 2021 at 03:37:11PM -0700, Aaron Jensen wrote:
> On Sun, May 23, 2021 at 2:08 PM Alan Third <alan@idiocy.org> wrote:
> >
> > > Interesting. And generally speaking, are there licensing issues
> > > preventing a merge/collaboration w/ the mac port?
> >
> > We already use the Mac port font backend (although I suspect they may
> > have diverged a little over time). Other than that I don't know how
> > much "collaboration" would be practical, and anything else would be simply
> > throwing the NS port out altogether and replacing it with the Mac
> > port, although then it would be subject to the same rules as the NS
> > port which may or may not be to Yamamoto Mitsuharu's taste.
> 
> I see, is that the rules about how nothing can be done in a Non-free
> OS port that a free OS cannot do?

I think so. A lot of what people like (smooth scrolling, etc.) would
have to be removed.

> > I've made surface-stuff as much like the (non-metal) mac port as I
> > possibly can. I'm not seeing any difference. I've put an NSLog at the
> > start of keyDown and another at the end of updateLayer, and the time
> > difference is pretty consistently about 3ms, so I don't think the NS
> > port's IO is slow. That leaves the time between the key being hit and
> > the NS port registering it, which I don't think we can do anything
> > about, or the time between us passing the IOSurface to the system and
> > it actually displaying, which should be identical to the Mac port,
> > unless it's using some sneaky setting I've yet to discover.
> >
> > If it's still laggy, I've got absolutely no idea.
> 
> Interesting. Well I know that my config is adding some latency. Likely
> company, flyspell, flycheck, etc. I'll keep digging on my end too.

One more thing to try...

modified   src/nsterm.m
@@ -8376,7 +8376,13 @@ - (void)unfocusDrawingBuffer
   NSTRACE ("[EmacsView unfocusDrawingBuffer]");
 
   [NSGraphicsContext setCurrentContext:nil];
-  [self setNeedsDisplay:YES];
+  [surface releaseContext];
+  [[self layer] setContents:(id)[surface getSurface]];
+  [surface performSelectorOnMainThread:@selector (getContext)
+                            withObject:nil
+                         waitUntilDone:NO];
+
+  //[self setNeedsDisplay:YES];
 }
 
 
@@ -8513,11 +8519,11 @@ - (void)updateLayer
      There's a private method, -[CALayer setContentsChanged], that we
      could use to force it, but we shouldn't often get the same
      surface twice in a row.  */
-  [surface releaseContext];
-  [[self layer] setContents:(id)[surface getSurface]];
-  [surface performSelectorOnMainThread:@selector (getContext)
-                            withObject:nil
-                         waitUntilDone:NO];
+  // [surface releaseContext];
+  // [[self layer] setContents:(id)[surface getSurface]];
+  // [surface performSelectorOnMainThread:@selector (getContext)
+  //                           withObject:nil
+  //                        waitUntilDone:NO];
 }
 #endif


All this does is reduce the time between us deciding we're done with
drawing and sending it off to VRAM (although it might not, I'm not
entirely sure when updateLayer gets called).

I expect this to reduce frame rate, but perhaps it will improve input
lag a little.

What's the overall situation just now with the various branches? I
don't actually care too much about frame rate, I think it's probably
fast enough in all cases, but I'm interested in input lag. Has
anything I've done improved it?
-- 
Alan Third