Re: macOS metal rendering engine in mac port

[Aaron Jensen]

On Fri, May 28, 2021 at 10:58 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Thu, 27 May 2021 12:37:33 -0700
> > Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org,
> >       YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> >
> > > As for times: do you want an optimized or an unoptimized build?  Does
> > > it matter if it's Emacs 27 or 28?  And does it matter that my builds
> > > are 32-bit builds --with-wide-int, which slows down Emacs by about
> > > 30%?  When I know which numbers you want to see, I will produce them.
> > > (Of course, it is easier for me to produce numbers from a build I
> > > already have, otherwise I'd need to build it first.)
> >
> > All my recent times are on unoptimized and on Emacs 28. I'm building
> > the default architecture on macOS, which I imagine is 64 bit.

I must have written this in a rush. I build optimized, not unoptimized.

> In an unoptimized 32-bit build --with-wide-int:
>
>   . Without line numbers: 15.9 sec.
>   . With line numbers: 19.7 sec.
>
> The times are quite consistent, with jitter of less than 0.1 sec.
>
> Note that I don't consider this (i.e. scrolling through a buffer that
> was already completely font-locked in advance) an important use case
> for the redisplay purposes, because with today's JIT font-lock this
> almost never happens.

Is that because the font-locking gets garbage collected over time? And
I agree, I don't think holding the scroll button down to get to the
bottom of the file is an important use case. It's just been used as a
proxy for rendering performance/framerate testing.