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 #358 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: Robert Pluim <rpluim <at> gmail.com>, 32932 <at> debbugs.gnu.org
Subject: Re: bug#32932: 27.0.50; render bugs on macOS Mojave
Date: Sat, 1 Feb 2020 14:22:42 +0000
On Fri, Jan 31, 2020 at 05:26:21PM -0800, Aaron Jensen wrote:
> On Fri, Jan 31, 2020 at 12:26 PM Aaron Jensen <aaronjensen <at> gmail.com> wrote:
> >
> > On Fri, Jan 31, 2020 at 12:23 PM Alan Third <alan <at> idiocy.org> wrote:
> > >
> > > I’m thinking of time spent in functions during, perhaps the scroll
> > > benchark, or just general use. I know it can be done through xcode and
> > > I think gperftools perhaps works on macOS.
> > >
> > > Alternatively I may be able to do it. Is it just a matter of grabbing
> > > the spacemacs config and using it, or do I need to do anything
> > > further?
> >
> > I don't actually use spacemacs anymore, I have my own config, but I
> > believe the slowness is reproducible in `emacs -Q` on my 4k monitor. I
> > don't have that machine here, but I can verify it when I get home. If
> > it is specific to my config, I can share it with you.
> 
> Hi Alan,
> 
> I just confirmed that it happens with emacs -Q. It's directly
> proportional to the size of the window. The default window size is
> pretty fast, but even a nearly blank buffer that's full screen lags
> when the point moves.

Thanks. I finally got my xcode install working again and tried just
profiling various actions and I think I know what’s going on.

NSBitmapImageRep is mutable, however it’s built on a CGImage or
something that isn’t, so every time you want to edit an
NSBitmapImageRep it has to copy the entire thing. This is why this
little bit of code to grab the bitmap’s graphics context

    [NSGraphicsContext
      graphicsContextWithBitmapImageRep:drawingBuffer]

is so damn slow and it gets slower as the screensize increases.

I’m now stumped because I can’t actually find any image type in the
documentation that isn’t immutable. I’m sure there must be something.
The Mac port appears to be using IOSurfaces, but as far as I can tell
they can be changed underneath you so aren’t much use for just
updating little bits of the Emacs frame at a time. I must be
misunderstanding something.

-- 
Alan Third




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

Previous Next


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