Re: macOS metal rendering engine in mac port

[Aaron Jensen]

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 don't really care one way or the other, I'm already using my new
> ThinkPad as my daily driver and it would be quite nice to see the back
> of the people on Reddit telling me I'm actively harming the Free
> Software movement by maintaining the NS port instead of letting it die
> so everyone is forced to use the Mac port.

Wow, people are jerks. I'm sorry you have to put up with that. For
what it's worth, I appreciate your work. I've never found the mac port
to work for me (though they just fixed the long-standing gui/tty
server issue which was a big one for me). This is the first time I've
used the mac port and thought ok, this may work, but then because it's
not on 28 yet, I miss native comp. I just can't have it all.

> > > 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.
> >
> > I've been using it and haven't seen any flickers. I'll continue using
> > it and report back. I probably would have seen one by now.
>
> My configuration seems to not even work with Emacs 27 any more, so I
> can't properly use it myself.

Copy that. I'll keep using it.

> On Sun, May 23, 2021 at 10:06:35AM -0700, Aaron Jensen wrote:
>
> Told you I'd back-port that fix. ;)

Hah, I wasn't going to say anything...

> I've seen similar, but only when I start the benchmark then click on
> another window. My thinking was that macOS was seeing I'm no longer
> using it and put it into some low-performance mode. But clicking back
> in the window doesn't fix it. I've no idea what's going on and I've
> only seen it happen when using the benchmark so I've not investigated.

Yeah, I wouldn't worry about it. I restarted and it was normal. 2.98s
for line numbers, 1.57s w/o. So still quite a bit faster than 28
surface stuff.

I also just tested macport with a stopwatch and it's very close to 28.
4.5s w/ line numbers.

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

Thanks,

Aaron