View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009201 | ardour | bugs | public | 2023-01-18 11:45 | 2023-02-10 00:59 |
| 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 | 7.2 | ||||
| Summary | 0009201: Slow Editor performance caused by the new opaque regions on Ardour 7.2 & Mixbus 8.2 Release! | ||||
| Description | The editor section is slow when zooming in and out of audio regions. | ||||
| Steps To Reproduce | this issue is noticeable with a good amount of tracks, however 1 or 2 tracks seem to be ok but in a real mix environment this is not ideal as the slow performance will occur when you are having a real world mix session, if you add lets say 16-30 tracks as a example and then you zoom in and out on all regions its very slow, also you will notice this when you set the Zoom setting to (Fit All Tracks) and when you scroll around/zooming in and out its slow. Prior versions such as 7.1 for Ardour and Mixbus 32c 8.1 did not have any issues with this. | ||||
| Additional Information | The new opaque regions seems to be causing this. Mixbus 8.1 and Ardour 7.1 do not have this issue, the only way to resolve this and get the same performance zooming in and out etc is to adjust the alpha setting to 0 which causes all audio regions to disappear and thus the perforce is back again but is useless due to the ability not to see your audio regions is gone. This new feature seems to be slowing down Ardour and Mixbus editor performance and should be changed and re-implemented in a way that doesn't create a performance hit. | ||||
| Tags | 7.2, 8.2, Ardour, Editor, MIxbus, performance, slow | ||||
| has duplicate | 0009203 | new | General UI slowness on an Intel Mac (compared to Ardour 6.9) |
|
|
I hope they can fix this issue. really been a drag and having to stay on older versions because of this. |
|
|
The problem is that this issue appears to be system-dependent. We have tried to reproduce it on various macs in our possession, and none of them show the issue. It therefore becomes unclear whether this is hardware dependent, or triggered by some 3rd party software, or specific to a very precise version of macOS, or something else. |
|
|
I’m not sure if all m1 users have this issue or if some do and don’t? I tested this on 2 m1 computers and they both have this issue, one of the computers has a more fresh install on Monetary Mac OS. I’m not sure if going to Mac OS Ventura would help, I also don’t know if the latest versions of ardour and mixbus are compiled for the latest Mac OS either. |
|
|
Also were any your tested machines powered by Apple silicon. This may be a apple silicon issue but I don’t know if I read that someone using Linux had the same issue or not. |
|
|
Yes, we've tested on 2 Apple Silicon systems. |
|
|
What version of OS was it tested on |
|
|
Also I know the slowness can be subjective to different people if they are not aware of use the program in different ways, example they may have a mouse with a slower mouse scroll speed for example. But on the systems you tested, there was absolutely no speed difference in the scroll speed or response rate of zooming in and out of all regions on screen on a large mix where all or most of the tracks or regions are displayed on the screen at the same time. I wish someone posted a video of their unaffected setup, it’s a bit discouraging since I tested on 2 different machines with same issue. Is this only a Mac OS issue, do people on windows or Linux have this issue at all? |
|
|
Nobody has reported this behavior for Linux or Windows. This is the sort of thing we've (and Reaper) have encountered in the past: https://user.cockos.com/~deadbeef/index.php?article=516 |
|
|
Oh ok, sometimes I really dislike Mac OS for when things are just complicated. I guess the only way to fix this is for ardour to reverse the feature that causes this, but I know that’s not likely going to happen since it doesn’t affect all of users. |
|
|
We won't reverse it for now, but not because it doesn't affect all users - more because we want to find a system where we can debug whatever is happening, and then fix it. |
|
|
Which operating system was it tested on. |
|
|
This issue seems to be a graphics acceleration issue. When disabled mixbus 8.2 works much smoother. However not sure on any possible cpu performance costs that I may face. |
|
|
@bsj Can you elaborate which, and how you "disable graphics acceleration" -- there are various options. I use Ardour on a M2 macbook air running Ventura 13.1, and do not have and issues. I do not use external screens though. I could imagine that perhaps using some external displays with color correction, esp non apple hardware, might have an effect. |
|
|
I disabled it via the settings/preferences menu, not via terminal code. Which I do want to try. However I’m not sure why some have this issue and some don't, when I disable the hardware acceleration it does improve and it does improve even more when I reduce my Mac OS resolution scaling. I’m not sure if I will have my CPU usage when running with disabled hardware acceleration, Does it also stop plugins from using GPU? When using ardour/mixbus I don’t see any GPU usage other than my plugins that use GPU so I don’t know what hardware acceleration is doing. Also I’m wondering how could this be resolved without disabling. I also was wondering if ardour can use something other than open GL for rendering, I know apple has their Metal API and I know there’s Vulcan. Not sure if this is just fantasy for a daw like ardour and mixbus to utilize. Also, have you tried loading up a typical mix session with about 16-30 tracks and set the zoom to fit so all regions fit on screen, then zoom in and out of all regions, are you saying that you don’t have any slow rendering or delayed loading etc. |
|
|
Ardour is 2D (not 3D), so neither Vulkan or Metal will help. openGL is used as work-around to bypass color-correction (see paul's post above) on older systems (until Catalina). I test with a session with 12 tracks visible, zoomed to show 5 seconds. With follow playhead as well as stationary playhead things are smooth using "more space" with the Retina screen. Quatrz debug reports 30 fps. |
|
|
Oh, so what about plugins that use GPU for GUI, I don’t think most plugins have any 3D elements to them. Also I always thought ardour and mixbus would be benefit from GPU acceleration based on how mixbus mixer GUI looks. Also what happens when you disable hardware acceleration if it doesn’t use GPU for rendering. |
|
|
With Hardware acceleration Ardour renders directly to a NSView. Without Hardware acceleration Ardour renders to an image-surface in memory and then the result is copied as bitmap to the NSView. |
|
|
Is their like a performance hit that is noticeable, is there a way I can see how it affects CPU? |
|
|
Could you try if changing the color profile helps? Set Apple System Preferences > Displays > Color Profile ... to Generic RGB Profile |
|
|
So I try this before or after I disable hardware acceleration? |
|
|
Disable HW acceleration. |
|
|
Well disabling hardware acceleration and changing colour profile didn’t help do bc anything different, when I do disable hardware acceleration it does speed up the editor section., |
|
|
Text is a bit blurry without hardware acceleration. So I have to keep that in mind also. |
|
|
Is their anything that ardour can do? |
|
|
We are continuing to evaluate, research and debug this issue. We do seem to have a system that shows the problem in front of of one of our developers now. |
|
|
Oh ok, this is great news, I hope it can be fixed. Not sure why only some have this issue like me and many others. |
|
|
Mixbus appears to have a version update that resolves this however with Harrison’s implementation it does have lower quality/resolution of the waveform view. I hope there is a way to fix this, it looks less sharp and the Color is dull compared to the default settings. |
|
|
There has been some some significant work in Ardour 7.2-250 (https://nightly.ardour.org) * partial exposure works now properly on macOS/OSX. Previously every redraw always painted the complete editor canvas -- this still happens with stationary playhead though * Colorspace correction is bypassed for the application - this speeds up bitblt * alpha-overlay calculation is now performed using dedicated asm code. * openGL can now upscale to Retina resolution * ... and if thing render still too slow, setting "region alpha" to 100% is now possible (Prefs > Appearance > Colors > Transparency) -- previously it got stuck at 98.9%. |
|
|
I assume that this is more work under the hood then what mixbus just released. I’ll check this out when I can |
|
|
It is in the Mixbus 8.2.170 hotfix. |
|
|
When I tried the mixbus 32C update fix it didn’t say or have option render for retina scaling l, I assume based on the quality it was only for low quality but was not labeled that. Ardour does have different wordings which I prefer, but strange thing is, on ardour nightlies, I tested it on my apple silicon computer and all the settings, the slow editor performance is somehow gone from my testing with 30 tracks. It was only 5-7 percent slower with the fixes enabled but when I clicked No for the option it was running at regular speed. Lol |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2023-01-18 11:45 | bsj | New Issue | |
| 2023-01-18 11:45 | bsj | Tag Attached: 7.2 | |
| 2023-01-18 11:45 | bsj | Tag Attached: 8.2 | |
| 2023-01-18 11:45 | bsj | Tag Attached: Ardour | |
| 2023-01-18 11:45 | bsj | Tag Attached: Editor | |
| 2023-01-18 11:45 | bsj | Tag Attached: MIxbus | |
| 2023-01-18 11:45 | bsj | Tag Attached: performance | |
| 2023-01-18 11:45 | bsj | Tag Attached: slow | |
| 2023-01-18 11:46 | bsj | Note Added: 0027187 | |
| 2023-01-18 14:42 | paul | Note Added: 0027190 | |
| 2023-01-18 14:59 | bsj | Note Added: 0027191 | |
| 2023-01-18 15:25 | bsj | Note Added: 0027192 | |
| 2023-01-18 15:39 | paul | Note Added: 0027193 | |
| 2023-01-18 21:31 | bsj | Note Added: 0027194 | |
| 2023-01-18 21:51 | bsj | Note Added: 0027195 | |
| 2023-01-18 22:45 | paul | Note Added: 0027196 | |
| 2023-01-18 23:32 | bsj | Note Added: 0027197 | |
| 2023-01-19 00:49 | paul | Note Added: 0027198 | |
| 2023-01-19 02:04 | bsj | Note Added: 0027199 | |
| 2023-01-19 16:59 | bsj | Note Added: 0027203 | |
| 2023-01-19 22:26 | x42 | Note Added: 0027204 | |
| 2023-01-20 00:42 | bsj | Note Added: 0027205 | |
| 2023-01-21 00:12 | x42 | Note Added: 0027207 | |
| 2023-01-21 00:45 | bsj | Note Added: 0027209 | |
| 2023-01-21 00:54 | x42 | Note Added: 0027210 | |
| 2023-01-21 02:00 | bsj | Note Added: 0027211 | |
| 2023-01-21 04:03 | x42 | Note Added: 0027213 | |
| 2023-01-21 04:40 | bsj | Note Added: 0027214 | |
| 2023-01-21 05:00 | x42 | Note Added: 0027216 | |
| 2023-01-21 06:06 | bsj | Note Added: 0027217 | |
| 2023-01-23 12:15 | bsj | Note Added: 0027222 | |
| 2023-01-31 04:19 | bsj | Note Added: 0027261 | |
| 2023-01-31 05:02 | paul | Note Added: 0027262 | |
| 2023-01-31 08:29 | bsj | Note Added: 0027263 | |
| 2023-02-04 18:47 | bsj | Note Added: 0027273 | |
| 2023-02-08 00:07 | x42 | Note Added: 0027316 | |
| 2023-02-08 02:02 | bsj | Note Added: 0027317 | |
| 2023-02-08 02:58 | x42 | Note Added: 0027318 | |
| 2023-02-08 02:58 | x42 | Note Edited: 0027318 | |
| 2023-02-08 02:59 | x42 | Note Edited: 0027318 | |
| 2023-02-08 10:05 | bsj | Note Added: 0027325 | |
| 2023-02-10 00:59 | x42 | Relationship added | has duplicate 0009203 |
