AsyncUpdater messages ignored during mouse down

Hi Jules,

I’m a bit puzzled by a mac-specific problem:

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?

Is this a bug? Can it be fixed or worked around?

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.


I’m glad to hear that I wasn’t completely mistaken.

How come that the mac mouse/menu stuff is such a pain? Is it a known weakness in the carbon event lib?

Also, I did not check, but ChangeListenerList messages should be equally affected by the mac mouse tracking message stall, shouldn’t they?

Anyway… do you have a rough priority for the task of fixing this issue on your (very long, I suppose) todo list?

I’m sorry I’m full of questions… and thanks for your quick reply :slight_smile:

It’s not that it’s done badly, it does seem to be the way they designed it. I guess if you’re just using mac APIs it all works as you’d expect.

I hadn’t realised before that this was happening, but it’ll be one of my top priorities to sort out…

Great! Thanks again.

Please do keep me posted :slight_smile:

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?

Yes, it’s an app.

That’s bad news you cannot reproduce the behavior…

Would you have time to investigate further if I sent you a minimalistic example application exhibiting the problem?

Sure - if you can give me something like that I’ll certainly take a look.