After upgrading the Electron runtime used by an NSB/AppStudio 9.5.1 application, a significant performance regression was observed on macOS. The application source code remained unchanged throughout testing. The Windows build remains fast and responsive.
I have attached a document with my findings.
Might need Electron’s help on this.
Thank you.
Electron_macOS_Performance_Regression_Report_for_NSB_AppStudio.zip (217.1 KB)
I fed your data in to Claude to see if it could suggest anything. The answer is interesting:
Good news — this is a well-documented issue, not something specific to AppStudio’s generated code. What you’re seeing on Electron 35+ is actually two separate problems layered on top of each other.
1. The macOS Tahoe “cornerMask” bug (this explains most of your data)
Electron overrides a private AppKit method called _cornerMask to smooth window corners on vibrant/transparent views. This method is called by WindowServer to calculate the shadow of the window, and this override broke something under macOS 26’s new rendering optimizations, causing WindowServer to repeatedly recalculate and repaint the window shadow — which is exactly why disabling hardware acceleration only partially helps: the damage is happening at the compositor/WindowServer level, not in your app’s own draw calls.
This was fixed by removing the cornerMask property and the private _cornerMask override so Electron stays on Apple’s default shadow path, and the fix landed in Electron v38.2.0, v37.6.0, and v36.9.2. That lines up almost exactly with your test matrix — 34.5.8 fast, 35.7.5–38.8.6 very slow (fix not yet backported), 40.8.0 and 43.1.1 “better but still not back to baseline” (fix is present, but see #2 below).
Apple also later shipped a system-level mitigation: macOS Tahoe 26.2 added a foundational fix that prevents any app from overloading WindowServer this way, regardless of which Electron version it uses. Since you’re on 26.4.1, you should already be getting that benefit — which suggests the residual slowness at 40.8.0/43.1.1 is a second, unrelated issue.
2. A separate, still-open Chromium layout regression
There’s a distinct, currently-unresolved bug where large-DOM pages get much slower forced-reflow/layout costs on newer Chromium versions. One reporter found a 10,000+ element page that re-rendered only changed elements in under 200ms on Electron 31, but the same update triggered a 1600ms “Forced reflow” layout task on Electron 38. Electron’s maintainers confirmed this also reproduces in plain Google Chrome, meaning it’s a Chromium-upstream bug that Electron can’t fix directly — it has to be fixed by the Chromium team, and they closed the issue as out-of-scope for Electron itself.
Your app is small (5–15 controls), so raw element count isn’t your problem — but AppStudio-generated apps do a lot of style/attribute mutation on interaction, and this class of bug is triggered by frequency of layout-invalidating changes, not just DOM size. That would explain degraded INP specifically (interaction-triggered layout thrash), even after the cornerMask fix landed.
Recommendations
BrowserWindow config sets vibrancy or transparent: true. The cornerMask override only fires for vibrant/transparent windows — if your login/main windows don’t need vibrancy, turning it off may sidestep this code path entirely, independent of Electron version.If you want, I can help you dig into the actual AppStudio-generated Electron main-process code to check the BrowserWindow options, or help draft this up as a report back to the AppStudio/NSB team with the version-fix mapping laid out.
Thank you, I will give the recommendations a try, and see how it goes. Thank you.