In AudioUnit editors the assumption Component::mouseEnter() → Component::isMouseOver() -> true doesn’t always hold true if Desktop::setGlobalScaleFactor() was called with a value unequal to 1.
I’ve included a drop-in replacement for AudioPluginDemo that demonstrates the problem. The demo’s global scale factor is 0.9. If you approach the hover target component slowly from the bottom edge you’ll see that it is being repainted with full opacity but the color doesn’t change to red (which is only the case if HoverTarget::isMouseOver() returns true).
The behavior is a bit host host dependent:
- On Reaper the problem is there in the beginning but disappears if the plug-in window is resized.
- On Ableton and Logic the problem isn’t there when instantiating a new plug-in but appears when resizing the plug-in window.
- On AudioPluginHost i fail to reproduce the problem
Investigating a bit further it seems that MouseInputSourceImpl::setPointerState is causing a mouseEnter event with the new pointer state (including position and componentUnderMouse) before updating lastPointerState. However Component::isMouseOver() is using MouseInputSource::getScreenPosition() to determine if Component::reallyContains() the position. When called from inside Component::mouseEnter() this value isn’t updated yet.
It isn’t entirely clear to me why this problem only occurs in this specific setup (i.e AU with scaleFactor) and isn’t more universal.
Our current work-around is to use
Component::isMouseOverOrDragging()which doesn’t check if the position is really contained in the component’s bounds.