bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third <alan@idiocy.org>]

On Wed, Jan 29, 2020 at 05:40:52PM -0800, Aaron Jensen wrote:
> On Wed, Jan 29, 2020 at 12:04 PM Alan Third <alan@idiocy.org> wrote:
> >
> > Can you try applying these three changes, and see if they make any
> > difference. I’d like you to try the first two both with and without
> > the third.
> 
> With regard to scrolling (full repaints) they make no difference,
> which you likely suspected. These are my scroll-up-benchmark times for
> one of my .org files:
> 
> Emacs 27: 2.6s
> 
> Emacs 28
> No patches: 13.0s
> First 2: 13.2s
> All 3: 13.8s
> 
> In terms of just repainting when I move the point, applying the first
> 2 patches made a noticeable difference. It is still sluggish compared
> to 27. I'm not sure I can tell a difference with the 3rd patch applied
> as well. It seems similar or maybe slightly faster.

Thanks for testing.

I see three probable places which might be making it very slow:

The obvious one is copying the bitmap to the screen in drawRect:. I
don’t think there’s any way around that other than working out how to
make better use of hardware acceleration with something like Metal.

For scrolling the actual process of copying a chunk of the offscreen
bitmap in copyRect: may be slow. Again we could probably improve that with some
sort of hardware acceleration.

The third place is getting the bitmap’s graphics context in
focusOnDrawingBuffer. I _know_ this is slow, and it’s possible,
probable even, that spacemacs causes it to happen far more often than
on vanilla Emacs.

It may be that we need to fix all of these, but is it possible for you
to run a profile and find out what’s using up the most time?

I’m wondering if it would be worth my time going onto, say, the Emacs
reddit and seeing if I can drum up interest from Mac developers. There
surely have to be SOME out there who use Emacs...
-- 
Alan Third