Emacs 29 flickering, slow

[jscheid]

Hi,

First of all I wanted to say thanks for your work on emacsformacosx.com, it's been my go-to for many years now.

Long version below but tl;dr is:

• Emacs 29 versions as published here misbehave on my system, with symptoms including flickering, sluggishness and potentially hard hangs.
• Emacs 29 built from source (with default config) doesn't exhibit the same problems, and is much snappier.
• Happy to help debug this.

The long version:

I'm running into troubles with Emacs 29.1-1 as published here (downloaded yesterday via the big button on your main page). I'm pretty sure I've seen the same with earlier versions of Emacs 29 downloaded from here, although I haven't tried reproducing it again with those earlier versions based on what I know now. Emacs 28 is fine.

The issues are a bit hard to describe but they manifest as flickering, sluggishness and occasional "full" hangs that I can't C-g out of, although I haven't had one of those recently and I can't be sure that the hangs aren't fixed by the latest version.

I've found the most reliable way to reproduce the flickering is to run magit-status (with latest vanilla magit from MELPA, no custom config). With the issue present, if the frame is sized so that Magit pops up on the right (rather than the bottom) then the whole frame will go blank while Magit is working, for 1-2 seconds or so. Without it, the part of the frame that isn't occupied by the Magit window stays as-is.

The frame going blank while magit-status runs is jarring, but I want to make it clear that the problem is more widespread. I've just found this to be a good proxy for the overall problem of the screen blanking a lot, which for short blanks manifests in flickering. At least that's my working theory.

None of this is an issue with Emacs 28 (as published here) and based on a quick poll on #emacs nobody else seemed to have heard of anything like it, so my first thought was a misconfiguration on my side. Maybe some old incompatible package lumbering around my .emacs.el, some .elc or .eln file produced by an older Emacs version or something like that. But I've started from scratch, reduced my config to the bare minimum needed to run Magit and I can still reproduce it.

My next thought was that it's a problem with Emacs proper, not with this distribution. I was already settling down for a night of bisecting, but to my surprise, the first build I made (from here) doesn't exhibit the flickering. (Built with just ./configure, i.e. default config arguments, and Xcode 14.0.3... which I should upgrade.)

What's more, this homegrown build is subjectively a lot snappier than the version I downloaded from here. I haven't run any proper benchmarks yet and this is a recent discovery so I couldn't tell you much more, but things like find-file feel instant now when before they were probably taking tens or even (low) hundreds of milliseconds in some situations.

I'm now aware of #107 and perhaps that explains the (lack of) snappiness but it feels to me that something else is going on. After all, native compilation shouldn't have any bearing on the display loop or rendering logic, I think? Besides, my understanding is that native compilation was added in Emacs 28 and that didn't flicker.

Anyway, I'm happy for now and I'll just use my own build. Do let me know if you'd like me to help you get to the bottom of this, though. If so it would be great if you could give me precise instructions on how to build a version locally as close as possible to the one that you're publishing here. I've poked around your build files hoping that I could find a simple configure line somewhere that I could use to try and reproduce, but I think it's more complicated than that.

My test environment: MacBook Pro 16-inch, 2019. 2.4 GHz 8-Core Intel Core i9, Intel UHD Graphics 630 1536 MB, 64 GB 2667 MHz DDR4, macOS 14.1.2 (23B92)

[jscheid]

Just a quick note that I've upgraded to Xcode command line tools 15.0.0 and rebuilt from scratch, and it's still working (snappy and not flickering.)

[jscheid]

I'm trying your build scripts. First, running just ./build-emacs-from-tar emacs-29.1.tar.bz2 release doesn't seem to work: logs (yes the output is garbled like that in my terminal)

Using the --verbose flag raises an error:

/path/to/build-emacs/verbose-shell.rb:16:in `block in system_trace': undefined method `=~' for ["rm", "-rf", "emacs-source"]:Array (NoMethodError)

The following works but prints warnings about "non-encapsulated libs":

./build-emacs-from-tar emacs-29.1.tar.bz2 release -j8 --no-dep

The resulting Emacs works like the ones I'm building manually: snappy and no flickering.

If you could let me know what to do about the error when building deps, I could try that again. If we can get that to work and the build result is also fine, then I guess that would point to the build environment (compiler and such), otherwise a problem with the dependencies.

Or I suppose there could be something with code signing or attestation, or the Rust wrapper, but I'm not immediately sure how to debug that.

[jscheid]

I've got ./combine-and-package Emacs-29.1-14-x86_64.tar.bz2 to work, but maybe the Readme should point out that one needs Ruby 2.x, run cargo build --release and copy the launch executable around.

Anyway, the result works fine. I haven't tried with code signing though.

[e40]

I don't have flickering, but I have the extreme sluggishness. It's really frustrating. I think I will try to build locally and see if that makes the problem go away.

I'm on a Mac Studio (max) with 64GB of RAM. Everything else on this machine is snappy as could be.

[e40]

I've got ./combine-and-package Emacs-29.1-14-x86_64.tar.bz2 to work, but maybe the Readme should point out that one needs Ruby 2.x, run cargo build --release and copy the launch executable around.

Anyway, the result works fine. I haven't tried with code signing though.

Hi, @jscheid I'm trying to build and having issues. Can you be more specific about the workaround? Thanks!

I just opened this issue related to my troubles: #142

[e40]

I've got ./combine-and-package Emacs-29.1-14-x86_64.tar.bz2 to work, but maybe the Readme should point out that one needs Ruby 2.x, run cargo build --release and copy the launch executable around.

Anyway, the result works fine. I haven't tried with code signing though.

Btw, this is what cargo build --release does for me:

@max[git:master]$ cargo build --release
    Updating crates.io index
 Downloading crates ...
  Downloaded foreign-types v0.3.2
  Downloaded objc v0.2.7
  Downloaded version-compare v0.1.0
  Downloaded core-foundation v0.9.2
  Downloaded cocoa-foundation v0.1.0
  Downloaded cocoa v0.24.0
  Downloaded regex v1.5.5
  Downloaded bitflags v1.3.2
  Downloaded regex-syntax v0.6.25
  Downloaded ryu v1.0.9
  Downloaded block v0.1.6
  Downloaded memchr v2.4.1
  Downloaded itoa v1.0.1
  Downloaded core-graphics v0.22.3
  Downloaded core-foundation-sys v0.8.3
  Downloaded aho-corasick v0.7.18
  Downloaded libc v0.2.112
  Downloaded serde_json v1.0.74
  Downloaded malloc_buf v0.0.6
  Downloaded glob v0.3.0
  Downloaded serde v1.0.133
  Downloaded foreign-types-shared v0.1.1
  Downloaded core-graphics-types v0.1.1
   Compiling libc v0.2.112
   Compiling core-foundation-sys v0.8.3
   Compiling foreign-types-shared v0.1.1
   Compiling memchr v2.4.1
   Compiling bitflags v1.3.2
   Compiling serde v1.0.133
   Compiling serde_json v1.0.74
   Compiling block v0.1.6
   Compiling regex-syntax v0.6.25
   Compiling itoa v1.0.1
   Compiling ryu v1.0.9
   Compiling foreign-types v0.3.2
   Compiling version-compare v0.1.0
   Compiling glob v0.3.0
   Compiling aho-corasick v0.7.18
   Compiling regex v1.5.5
   Compiling core-foundation v0.9.2
   Compiling malloc_buf v0.0.6
   Compiling objc v0.2.7
   Compiling core-graphics-types v0.1.1
   Compiling core-graphics v0.22.3
   Compiling cocoa-foundation v0.1.0
   Compiling cocoa v0.24.0
   Compiling emacs-launcher v0.1.0 (/Users/layer/src/import/build-emacs)
error[E0554]: `#![feature]` may not be used on the stable release channel
  --> launch.rs:36:1
   |
36 | #![feature(exit_status_error)]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0554`.
error: could not compile `emacs-launcher` (bin "launch") due to 1 previous error
@max[git:master]$ 

[jscheid]

Hi @e40, in the meantime I've given up on this Emacs build. I'm now using Emacs+ and that doesn't seem to have the same problems, and seems to "just work".

I don't actually need the "plus" stuff, whatever that means, it's just a build that doesn't have the problems I had described here. Can recommend.

[e40]

Hi @e40, in the meantime I've given up on this Emacs build. I'm now using Emacs+ and that doesn't seem to have the same problems, and seems to "just work".

I don't actually need the "plus" stuff, whatever that means, it's just a build that doesn't have the problems I had described here. Can recommend.

Thanks, @jscheid. I will try that version. I've used this version of emacs for so long, it makes me sad to switch, but the sluggishness is really getting to me.

[jscheid]

Good luck!

[caldwell]

Thanks, @jscheid. I will try that version. I've used this version of emacs for so long, it makes me sad to switch, but the sluggishness is really getting to me.

Is the sluggishness happening when you are using eglot (or the other LSP mode)?

One thing I've seen is that Emacs.app for some reason gets marked to run under rosetta (even though there's a native arm binary included). If everything is sluggish, go into Finder and "Get Info" on the "Emacs.app" in your Applications folder (or wherever you launch it from). Make sure that the "Open using Rosetta" checkbox is not checked.

[caldwell]

   Compiling emacs-launcher v0.1.0 (/Users/layer/src/import/build-emacs)
error[E0554]: `#![feature]` may not be used on the stable release channel
  --> launch.rs:36:1
   |
36 | #![feature(exit_status_error)]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0554`.
error: could not compile `emacs-launcher` (bin "launch") due to 1 previous error
@max[git:master]$ 

That's because I used a feature that's only available in Nightly Rust builds. rustup toolchain install nightly will install the nightly version of Rust. But I'll push a patch shortly that will just switch the code to use a stable feature instead.