Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

> Date: Sat, 29 May 2021 12:37:00 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: aaronjensen@gmail.com, emacs-devel@gnu.org
> 
> > Date: Sat, 29 May 2021 10:32:00 +0100
> > From: Alan Third <alan@idiocy.org>
> > Cc: aaronjensen@gmail.com, emacs-devel@gnu.org
> > 
> > Yes, I think that's what I'm talking about. There's a lot of code like this:
> > 
> >   struct face *face = FRAME_DEFAULT_FACE (f);
> >   [ns_lookup_indexed_color (NS_FACE_BACKGROUND (face), f) set];
> > 
> > and
> > 
> >   if (s->hl == DRAW_MOUSE_FACE)
> >     {
> >       face = FACE_FROM_ID_OR_NULL (s->f,
> >                                MOUSE_HL_INFO (s->f)->mouse_face_face_id);
> >       if (!face)
> >         face = FACE_FROM_ID (s->f, MOUSE_FACE_ID);
> >     }
> >   else
> >     face = s->face;
> > 
> > Which I don't think is present in the other terms, because, as I say,
> > they look them up in one function rather than spread out throughout
> > the term's code.
> 
> I cannot see why this would be a problem.  First, FACE_FROM_ID and
> FACE_FROM_ID_OR_NULL simply access a face by direct indexing into the
> frame's face cache, so it's just a couple of CPU instructions.  And
> second, I see very similar code in other *term.c sources, so I don't
> think nsterm.m does it very differently.

Of course, what I say above doesn't include ns_lookup_indexed_color,
so maybe that could explain some slowness?