Re: macOS metal rendering engine in mac port

[Alan Third]

On Sat, May 29, 2021 at 12:26:10PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 29 May 2021 10:12:26 +0100
> > From: Alan Third <alan@idiocy.org>
> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> > 
> > One thing I know that's odd in the NS port is that we work out which
> > face we need on the fly, whereas the other terms seem to have a
> > central function that works out the faces early.
> 
> What do you mean by "which face" (singular)?  Redisplay of a typical
> buffer under a major mode such as CC Mode usually needs to use and
> merge about a dozen of different faces (think font-lock), so there
> isn't a single face to figure it out.  Maybe you mean the default
> face?  That one gets computed whenever we start the display operation,
> such as redisplaying a window, and is reused until we are done with
> the window.  Then we compute it again when (or if) we go to redisplay
> another window.

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.

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