I’ve now had to reinstate 'Use macOS to determine GUI redraw areas’ as it was that which was causing the disappearing window elements.
Now I’m really stumped.
What macOS version do you run? Is this a mac-mini with external display, or a macbook with Retina display? Intel or Apple Silicon?
tech-details:
Recent versions of macOS always ask Applications to redraw the complete GUI, even if nothing has changed. This slows things down.
When turning off “*Use visibility information provided by …”, Arodur keeps track of areas to be redrawn. However in some cases (mostly with external displays) that can lead to parts of the GUI disappearing (until you mouse-over). For unknown reasons parts of the GUI that didn’t change need to be redrawn anyway.
I’m using OS 15.5 on a Mac Studio with 32GB RAM & 4TB SSD into a HP ultrawide (32:9) curved monitor and an ultrawide LG monitor (16:9).
Audio i/f is a Behringer UMC 404HD, fed with USB Audio. Controllers are Arturia Keylab Essential 49 Mk. 3 and a Tascam DM-4800 (USB/Logic Control)
Well, I’ll give it one more go tomorrow and if it’s still slow I’ll go back to Logic until v9 rolls out.
Sadly, it is unlikely that the actual release of v9 will behave any differently. We have only seen this problem on specific (recent) versions of macOS when used with multiple monitors. Needless to say, that makes figuring out the cause rather challenging …
Bugger. That’s disappointing. I really love how Ardour works and seems more configurable and professional than Logic. It’s a pity that certain configs of Mac s/w & h/w hold back the development of a fine DAW on tha platform. I use an ultra-wide 32:9 and 21:9 monitors. Maybe they’re the culprit in some way.
Hi folks !
I also face the same issue since I moved from Ventura to Sequoia on my Macbook Pro retina from 2019 (no external screen here). Ardour 8.12. The meters lag like hell and some plugins behave funny (MLoudness analyser and MEqualizer from MeldaProductions).
I tried ‘Use visibility information provided by your Window Manager/Desktop’
and
Use macOS to determine GUI redraw areas’
The first one did nothing I could notice, the later solved the lag issue (not the plugin issue) but then Ardour became unusable like this (picture attached)
I love Ardour as I try to escape from proprietary software (Logic & Mac) but here it makes it very hard to use.
Any help would be appreciated.
Stephane
1 Like
Yes, Ardour seems to suffer from several GUI bugs/issue for macOS in particular.
Hopefully the devs will iron-out these issues in the build-up to v9.
You’re always welcome to go file a bug report, too, to keep up the pressure on them… : P
Sadly there’s no further help coming to this issue for the foreseeable future. It is specific to combinations of specific macOS releases and monitor configurations. If you have one of the “bad” combinations, we have no solution. Apple changed the way their GUI systems work, we did what we can to work with their new design, and that breaks on those “bad” combinations.
Can you point me to some (Apple/other) documents so I can understand what specifically you mean by this?
Nope, because they didn’t document it. It is mentioned in a couple of posts on apple forums over the last 10 years, that’s all.
The “normal” way that GUI systems work is that when something needs to be redrawn (e.g. because a meter level has changed, or a knob has been turned, or a new character has been typed) is that the program tells the window system to “invalidate” a shape (normally a rectangle). At some point in the near future, the window system will in turn tell the program “redraw these areas”, and will supply a list of one or more rectangles that need to be redrawn.
macOS used to work this way, and the documentation still says it works this way, but it does not. If you invalidate a 10x10 pixel area in a window, macOS now tells you to redraw the whole window.
A number of other application developers noticed this too and complained to Apple in their forums. Apple’s response has been “we no longer keep track of that for you, you’ll need your own mechanism to decide what needs to be redrawn”.
2 Likes
Great theme! Maybe it could be included in Ardour 9 as the ‘nature’ theme… 
Jokes aside, this whole thread shows that maybe Wayland isn’t the worst thing to ever happen. Sounds like Apple did a pretty good rug-pull there… 
1 Like
Yes very inspiring I have to give it that ! My music suddenly turned all ambient landscapes 
Now that I am totally relaxed I will dare downgrading to Ventura which was totally fine with this. Was not expecting such a disappointment. 
1 Like
So, I took a look at this problem and they mention a few things that might be worthy to investigate.
- This Stack Overflow Question took me to the AppKit docs https://stackoverflow.com/questions/77375566/macos-app-has-broken-ui-on-sonoma-macos-14-but-only-when-buiding-it-with-xcode
- The AppKit docs effectively explains that we need to define a variable that used to be enabled by default AppKit Release Notes for macOS 14 | Apple Developer Documentation
- This is the Property definition according to their docs clipsToBounds | Apple Developer Documentation
Now, that being said, I’ve tried searching across the project for that variable and I was unable to find it, being completely honest I also don’t know how to get started, if anyone can point me out how to give it a try, I might be able to experiment a little and maybe, if life is easy and things don’t get hard, come up with a solution(?)
I’ve checked the nsglview.mm file which I assumed is the main View/artifact for macos, but again, no sure; this is the first time I try to get in the Ardour’s code based but I would love to give it a try.
Those are the files I can see as mm files (assuming ObjC for macOS only?)
On another note, and just for the OP, I do use Ardour on my macOS (macbook pro M1), I had both the Use visibility information provided by your WIndow Manager/Desktop and Use macOS to determine GUI redraw areas flags enabled and working as expected.
It is true that sometimes the meters felt a little slower, and they get faster after removing the flags, but by doing so I have fallen into the Glitchy UI issue, I’ve tried with an 8 Channel multiple plugins session and it works well, not super fast but good enough to keep working.
1 Like
yep, though the issue at hand is at a lower level in libs/tk/ydk/quartz/*
It is also unclear if the SDK used at build-time plays a role.
Similar here. I run Ardour on a MacBook Air, M2 Sequoia 15.6.1 without issues.
1 Like
As a side note, I’d estimate that between @x42 and myself, we’ve put more than 40 hours over several years into this issue already, and have done exhaustive network searches to find out more.
That doesn’t mean that nobody else should look at it, because sometimes fresh eyes find new solutions, but don’t be under the impression that we’ve avoided this problem. We’ve put serious time into finding solutions, and what we have now is as good as we’ve gotten.
4 Likes
To me, this sounds like something that’s been designed to deliberately undermine non-Apple developers - and let’s face it, it wouldn’t be the first time! I can’t believe that Apple itself is redrawing the whole window every time a few pixels need to get updated.
1 Like
Nobody is redrawing the whole window when just a few pixels need updating, but the question is: how to keep track of what needs redrawing under a variety of circumstances, now that the OS layer is not doing this for us.
We have our own solution, no doubt others have developed their own. But for specific combinations of SDK/macOS release/monitor configuration, ours doesn’t work all the time.
1 Like
3rd-party developers should gang up on Apple and threaten to stop developing for the platform (though I’ve a suspicion that might just be what Apple wants 
)
1 Like
Don’t worry about that, I didn’t have that impression.
One funny thing about software is that the docs can get stale very quickly and something that was documented might not work as expected (or the actual opposite, something that they said should work on a given way is no longer true), also, the fact that they single-handedly removed the OpenGL support is very impactful; I was mainly looking for pointers on how I probably can get started, but it’s also true that the level of effort it would imply to me is way bigger since I’m not familiar with this code yet.
Again, it completely makes sense if you don’t want to get back to this at the moment since it’s working well enough (as you mentioned in previous messages).
Thanks again both for replying really fast.