Re: macOS metal rendering engine in mac port

[Eli Zaretskii]

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

> But again, I don't think this should recalculate anything. Macros like
> FACE_FROM_ID_OR_NULL appear to be doing simple lookups that shouldn't
> slow anything down, unless I'm missing something.

Exactly.