Subject: Re: bug#32932: 27.0.50; render bugs on macOS Mojave

From: Aaron Jensen <[email-masked]>
Date: Sun, 2 Feb 2020 08:49:44 -0800

On Sun, Feb 2, 2020 at 5:42 AM Alan Third <[email-masked]> wrote:
>
> Out of interest, is the mac port fast under the same conditions? Here
> their performance seems to be almost identical with the mac port only
> fractionally faster, and their performance scales similarly with frame
> size.

For scrolling/full repaints the mac port is significantly faster,
similar to repaint speed of cursor moves. With the patch, Emacs 28's
full repaint when taking about 3/5s of my screen takes about 400ms
whereas it's about 16.7ms (60fps) with mac port. Emacs 27 seems to
paint even faster than that.

Also, I misstated my screen's specs, it's not a 4k display it's a 5k2k
screen with a native resolution of 5120 x 2160. So, it's as tall as
4k, but wider. I don't generally use emacs full width, however.

On Sun, Feb 2, 2020 at 5:46 AM Alan Third <[email-masked]> wrote:
>
> > Cures the speed problems for me, but the text became fuzzy (MacBook Pro Retina).
> > Two Emacs instances, without and with the patch:
>
> Thanks for testing it. I think the fuzzyness is just the pre‐mojave
> anti‐aliasing coming back. I don’t know why.

Ah, good eye. Mine is blurry too. Could it be creating a layer that is
the size of hidpi scaled window but not the actual pixel size of the
window? That would explain the blur if it was then drawn to a larger
pixel-wise window.

> I think that second URL is wrong, but I’ve read that quote before.
> Normal double buffering is simply drawing like we do on Emacs 27.
> There are plenty of places in the documentation that push you towards
> just drawing when you want to recreate part of the screen, however as
> we know Emacs redisplay isn’t really amenable to that approach.

Do you know the cause of the glitching? Or is that still unclear? I
wonder if we could take some time to walk through it together, maybe
something will stand out?

Thanks,

Aaron