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

Previous Next

Package: emacs;

Reported by: Aaron Jensen <aaronjensen <at> gmail.com>

Date: Thu, 4 Oct 2018 13:07:02 UTC

Severity: minor

Tags: fixed

Merged with 31904, 33891, 34127, 34710, 36302

Found in versions 26.1.90, 26.1.91, 26.2.90, 27.0.50

Fixed in version 28.1

Done: Alan Third <alan <at> idiocy.org>

Bug is archived. No further changes may be made.

Full log


Message #334 received at 32932 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 32932 <at> debbugs.gnu.org
Subject: Re: bug#32932: 27.0.50; render bugs on macOS Mojave
Date: Thu, 30 Jan 2020 19:11:54 +0000
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 <at> 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




This bug report was last modified 5 years and 94 days ago.

Previous Next


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