View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010293 | ardour | bugs | public | 2026-04-22 03:47 | 2026-07-28 07:56 |
| Reporter | bsj | Assigned To | |||
| Priority | high | Severity | major | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | Apple Macintosh | OS | MacOS | OS Version | 10.12 or later |
| Product Version | 9.2 | ||||
| Summary | 0010293: Enhancement Request: Improved UI Thread Efficiency and Meter Redrawing on macOS (Apple Silicon) | ||||
| Description | On modern Apple Silicon hardware (specifically the M4), Ardour 9.x experiences significant GUI sluggishness as the track count increases, even when CPU and GPU usage are low. While a session with 1-4 tracks feels "musical" and snappy, the meter response becomes visually "heavy" and disconnected once the track count reaches 10-16 tracks and beyond. This occurs in a completely empty session with no third-party plugins. Currently, the only workaround to regain smooth metering is to hide or disable tracks etc. I wish Ardour was Metal or Vulkan accelerated!!!!! | ||||
| Steps To Reproduce | very simple, keep adding tracks and the meters will evenly get worse and worse less snappy with no plugins just an empty session no matter buffer size. | ||||
| Additional Information | Technical Observations: Hardware: Apple M4 (Base model), macOS [Insert your version, e.g., Sonoma]. Behavior: The issue appears to be GUI Thread Contention. Hiding tracks immediately restores fluidity, suggesting that the redraw requests for multiple active meters are flooding the main UI thread. Ineffectiveness of Current Settings: Toggling "Use intermediate image-surface," "Retina scaling," and various "macOS Drawing Models" does not fully resolve the scaling issue. Redraw Overhead: It appears macOS may be forcing expensive full-window or large-area redraws for every meter update, causing the UI to fall behind the audio engine's "musical" timing. | ||||
| Tags | GUI, lag, slowdowns, sluggish | ||||
|
|
There is no GUI thread contention, because the GUI is 100% single threaded. The issues with macOS redrawing are deep and subtle. macOS itself indeed forces full-window redraws for every meter update (a change Apple made 6-8 years ago, without announcing it), which is why we (and many other apps) had to add our own system of keeping track of what areas need updating. However, recently I've observed that even when our code does the right thing, macOS' lower layers do not appear to always flush just-drawn areas to the screen if they are small. I am still (slowly) investigating what could cause this and how to fix it. |
|
|
I reported this as 10450 before finding this issue. Looks like the same problem. Looking at a trace in Instruments, it looks like it spends most of its time in CG::DisplayList::executeEntries, and of that a bunch in things like CGClipCreateWithPath. A lot of the traces wind up in things like malloc and memmove. This sounds like Ardour/cairo is possibly creating a huge amount of tiny draws for CoreGraphics to process? It doesn't look like it spends most of the time actually *drawing* anything in terms of pixels. On a hunch I tried this: diff --git a/libs/widgets/fastmeter.cc b/libs/widgets/fastmeter.cc index bea228b84a..09d1e96db0 100644 --- a/libs/widgets/fastmeter.cc +++ b/libs/widgets/fastmeter.cc @@ -757,9 +757,10 @@ FastMeter::queue_vertical_redraw (const Glib::RefPtr<Gdk::Window>& win, float ol rect.x = 1; rect.width = pixwidth; - rect.height = new_top; - rect.y = 1 + pixheight - new_top; + rect.height = pixheight; + rect.y = 1; +#if 0 if (current_level > old_level) { /* colored/pixbuf got larger, just draw the new section */ /* rect.y stays where it is because of X coordinates */ @@ -776,6 +777,7 @@ FastMeter::queue_vertical_redraw (const Glib::RefPtr<Gdk::Window>& win, float ol */ rect.height = pixrect.height - rect.height; } +#endif GdkRegion* region = 0; bool queue = false; And that significantly *improved* the issue. I think what is happening is that Ardour's dirty-rectangle tracking thing to minimize draw areas is actually completely thrashing CoreGraphics. I think CG is trying to draw the entire surface every frame, and it does so in a deferred processing call. When Ardour calls into cairo which forwards to CG, no drawing happens, but instead CG records *the operations needed to draw that area of the screen*. When Ardour does its own dirty-rect tracking, as it does for meters, this means that behind the scenes CG actually ends up splitting the meter into a zillion little rects in its drawing list, each recording the operations Ardour performed when it last drew those pixels. Then on every frame, it walks the entire screen to draw everything from scratch. This ends up drawing the same number of pixels in the end, but the CPU is completely thrashed by overhead tracking tiny little areas to draw individually. This is why when the meters get "reset", it briefly speeds up. At that point the entire meter is drawn as one unit, and this cleans up the CoreGraphics display list for that area of the screen. Then as the meters move, it gets thrashed. This also explains why tracks that are silent don't contribute much (those meters are not moving so aren't thashing). It's not just the meters; this also explains why clicking on a track slows things down again. Essentially, any time there is a partial redraw of anything by Ardour, things get worse. By trying to draw less per frame, Ardour is actually creating a pathological situation for CoreGraphics. I have no idea whose fault this is, or whether this "deferred redraw" behavior can be turned off anywhere, but I can think of two ways forward: - Turn off dirty rect logic across the board and just redraw everything each frame - Draw everything to an offscreen surface (that is known to be flushed to pixels, no display list nonsense behind the scenes), then just blit to the screen each frame. |
|
|
@lina Wow, you are very astute with all this. O___o -Great job! : ) I hope @paul reads your ideas/observations here. -J |
|
|
I suspect this is related: https://gitlab.gnome.org/GNOME/gtk/-/work_items/3714 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-04-22 03:47 | bsj | New Issue | |
| 2026-04-22 03:47 | bsj | Tag Attached: GUI | |
| 2026-04-22 03:47 | bsj | Tag Attached: lag | |
| 2026-04-22 03:47 | bsj | Tag Attached: slowdowns | |
| 2026-04-22 03:47 | bsj | Tag Attached: sluggish | |
| 2026-05-02 16:35 | paul | Note Added: 0030314 | |
| 2026-07-28 07:14 | lina | Note Added: 0030611 | |
| 2026-07-28 07:33 | GhostsonAcid | Note Added: 0030612 | |
| 2026-07-28 07:56 | lina | Note Added: 0030613 |
