TooltipWindow scaling issue in Windows High-DPI plug-in

Audio Plugins
1

Hi

I am creating a TooltipWindow in the recommended way which I believe attaches it to the desktop.
SharedResourcePointer<TooltipWindow> tooltip_window;

It works as expected in MacOS, but in Windows hosts when set to High-DPI mode (e.g. Studio One 3, FL Studio) the tooltip is showing as very small as though it does not know it needs to scale to double the size.

Thanks
Matt

1 Like
2

The TooltipWindow will already scale correctly if you instantiate it with a parent component (for example your editor). It will then scale according to your editor. Therefore you should do the following:

class MyEditor : public AudioProcessorEditor
{
    //...
private:
     TooltipWindow tooltipWindow {this};
};

Previously the TooltipWindow would assert if there would be multiple TooltipWindows. I’ve just pushed a commit which fixes this assertion and allows multiple TooltipWindowss as long as they have distinct parent components. The commit will appear on develop in a few moments.

There really isn’t a better option to solve this problem. VST3 and VST2 allows the host to set a per editor scaling factor, therefore, we can’t apply a global scaling factor to the TooltipWindow (it must be per editor).

Another option would be to scale the TooltipWindow according to the AffineTransform of the component for which the TooltipWindow is currently showing a tooltip (<- ok my brain is hurting just from writing that sentence). However, there are a lot of components which use an AffineTransform purely for some graphical effect and that should not affect the size of the tooltip window IMHO.

1 Like
3

Thanks. Sorry, this is probably a basic C++ knowledge gap, but taking your example and putting it in a SharedResourcePointer, how do I pass this to the constructor in that case?

private: SharedResourcePointer<TooltipWindow> tooltip_window;

4

I don’t think you can do that with SharedResourcePointer. However, I don’t think you need to use it anyway. Simply have a TooltipWindow as a member variable in your editor, just like my code listing in my post above.

5

Happy to do that if the advice that we should use it to avoid multiple instances is not applicable anymore following your updates:

From: JUCE: TooltipWindow Class Reference

Note that if you instantiate more than one instance of this class, you’ll end up with multiple tooltips being shown! This is a common problem when compiling audio plug-ins with JUCE: depending on the way you instantiate TooltipWindow, you may end up with a TooltipWindow for each plug-in instance. To avoid this use a SharedResourcePointer to instantiate the TooltipWindow only once.

6

Yes I’ve changed the documentation on develop with the above commit already. The website reflects the documentation on master.

7

Thanks, that’s sorted it all.

8

Is there any solution that will fix this for desktop TooltipWindow’s (i.e. that aren’t attached to the editor)? We use desktop TooltipWindow’s so that we can get the system-provided drop shadow.

We’ve tried also using the DropShadower with a TooltipWindow attached to the editor, but that also has issues: DropShadower artifacts when transformed.

9

This appears to be an issue again 6.0.8 – I’m using tooltips attached to a parent & they’re not scaling correctly when using affine transforms on the parents. Should there be some sort of scale factor applied?