GNU bug report logs - #32932
27.0.50; render bugs on macOS Mojave

Previous Next

Full log

View this message in rfc822 format

From: Alan Third <alan <at> idiocy.org>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: Mattias Engdegård <mattiase <at> acm.org>, Robert Pluim <rpluim <at> gmail.com>, 32932 <at> debbugs.gnu.org
Subject: bug#32932: 27.0.50; render bugs on macOS Mojave
Date: Sun, 2 Feb 2020 22:30:52 +0000

[Message part 1 (text/plain, inline)]

On Sun, Feb 02, 2020 at 08:49:44AM -0800, Aaron Jensen wrote:
> On Sun, Feb 2, 2020 at 5:42 AM Alan Third <alan <at> idiocy.org> 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.

Amazingly the attached patch is faster than the mac port on my machine
(13" retina macbook pro) in the scroll test.

I can’t see that holding for your screen, though.

> On Sun, Feb 2, 2020 at 5:46 AM Alan Third <alan <at> idiocy.org> 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.

So turns out you need to do some fancy‐pants manoeuvres to scale
CGLayers correctly. They also appear to draw faster when correctly
scaled, presumably because it’s not having to scale everything while
drawing to the screen.

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

I know exactly what’s causing the glitching, but I’ll come back to
this tomorrow.
-- 
Alan Third

[v2-0001-Use-CGLayer-instead-of-NSBitmapImageRep-bug-32932.patch (text/plain, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.