Our application has AsyncUpdaters that do background stuff (low-priority asynchronous buffered audio decoding) in a background thread and trigger async updates periodically.
The async updates are handled in the message manager thread and often induce component (a waveform display) repaints.
This is working very fine on Windows and Linux, so far so good.
The trouble is: on the Mac (MacOS X 10.4.10 on an Core Duo 2 MacBook), the async updater messages seem to be blocked whenever any mouse button is maintained down, anywhere on the main window (even over a completely passive component), and the gui does not get updated until the mouse button is released.
I tried to find the guilty parties, playing around with the trackNextMouseEvent stuff in juce_mac_Windowing, but miserably failed to solve the issue.
I could not observe this behavior in the demo, because all the animated stuff is triggered either by timers or by thread-specific callbacks, which aren’t affected by the message queue flushing behavior.
Is my design flawed? Is this a bad idea to use AsyncUpdaters for real-time gui updates of a waveform display?
The mac mouse-tracking stuff is nasty, because it deliberately stops messages being delivered. Menus do the same thing, and it’s all a bit of a pain. I think I bodged it to make sure that timers got through, but maybe it needs some similar bodging for the kind of messages that asyncupdater relies on.
So no, your design’s not flawed, it’s my end that should make sure it all works, even if the mac makes life difficult for this kind of thing.
Sorry - ignore my earlier comments, I was thinking of what happens when you drag on a native title bar or menu.
I can’t find anything wrong with asyncupdaters in terms of normal juce components, and have no idea why it’d fail. This is an app, right? Not a plugin?
