[Bug]: Tooltip does not show with rapidly changing tooltip even when `millisecondsBeforeTipAppears = 0`

[YellowVanAudio]

Detailed steps on how to reproduce the bug

The context of this bug is that I'm trying to display a tooltip over a VU meter with the current level. The tooltip therefore changes at every paint (unless the audio is perfectly steady, or silent, for example).

In juce_TooltipWindow.cpp, the logic on when a tooltip displays (TooltipWindow::timerCallback()) is:

A tooltip has changed when:

• When the text of the tooltip is new OR
• When the source component of the tooltip changed.
  Then the tooltip should show when millisecondsBeforeTipAppears has passed.

            // if there isn't currently a tip, but one is needed, only let it
            // appear after a timeout
            if (newTip.isNotEmpty() && newTip != tipShowing &&
                now > lastCompChangeTime + (uint32) millisecondsBeforeTipAppears)
            {
                showTip();
            }

I believe that his > and should be >=. In my case, I purposefully set millisecondsBeforeTipAppears to 0, but still no tooltip appears, because when the tooltip changes every frame, now is always equal to lastCompChangeTime and never greater.

Fixes:

• Option 1: change the > and should be >=
• Option 2: remove the static cast to uint32 - this will allow the user to put -1
• Option 3: I personally don't think I agree with the text comparison to determine whether a tooltip has changed, I think only the source should deterimine that. Or potentially this could be an optional setting to the TooltipWindow.

Temporary work
This is obviously a hack, but the workaround to fix my tooltip and make it appear is literally:

juce::TooltipWindow tooltip_window_;
my_tooltip_window_.setMillisecondsBeforeTipAppears((uint32_t)-1);

This is still bad though, because the only option this way is that a tooltip immediately shows - a delay doesn't work this way. For that, the only viable solution is the Option 3 from above.

What is the expected behaviour?

Tooltip should show after the designated delay, definitely if that delay is 0.

Ideally, also after delay this works, but that can only work if the text-based string compare is not a required, which will be a change in behaviour. Optionally this could be an extra setting/flag.

Operating systems

Windows, macOS, Linux

What versions of the operating systems?

All desktop OS, i.e. those that allow hovering + tooltips

Architectures

x86_64, Arm64/aarch64, Arm64EC (Windows), x86 (Windows, Android), 32 bit Arm (Linux, Android)

Stacktrace

Plug-in formats (if applicable)

No response

Plug-in host applications (DAWs) (if applicable)

No response

Testing on the develop branch

The bug is present on the develop branch

Code of Conduct

• I agree to follow the Code of Conduct

[ferdnyc]

• I personally don't think I agree with the text comparison to determine whether a tooltip has changed, I think only the source should deterimine that. Or potentially this could be an optional setting to the TooltipWindow.

Well, no, because keep in mind tooltips are meant to be shown automatically on mouse hover. "The source" is typically a component with a callback set on it, and a string stored in a property. There's no "source" logic regarding updates of the tooltip at all, just what the TooltipWindow applies when it's triggered. So, those kinds of checks are necessary protections against things like the tooltip constantly being repainted every time the mouse moves, even if its contents are the same.

I think you need to consider that a tooltip may not be the right way of implementing this. You're probably better off creating your own widget that you can show on hover, and update as rapidly as you need using events from the meter.

[ferdnyc]

This is obviously a hack, but the workaround to fix my tooltip and make it appear is literally:

juce::TooltipWindow tooltip_window_;
my_tooltip_window_.setMillisecondsBeforeTipAppears((uint32_t)-1);

The only reason that works is because the tooltip timerCallback logic contains this (and it's arguably a bug that it does work, and doesn't reject negative values for millisecondsBeforeTipAppears):

JUCE/modules/juce_gui_basics/windows/juce_TooltipWindow.cpp

Lines 253 to 259 in 7c9d378

	// if there isn't currently a tip, but one is needed, only let it appear after a timeout
	if (newTip.isNotEmpty()
	&& newTip != tipShowing
	&& now > lastCompChangeTime + (uint32) millisecondsBeforeTipAppears)
	{
	showTip();
	}

So, because it ends up adding -1 to lastCompChangeTime, now is greater even if lastCompChangeTime == now, and you break the protection against excessive repaints.

(Edit: Belatedly I realized it does reject negative values, in the sense that millisecondsBeforeTipAppears is an unsigned integer. So really you're causing an overflow, when lastCompChangeTime is added to (uint32)-1 which is a very big number. Result is the same, now tests greater even though lastCompChangeTime == now.)

(Edit2: This is also where JUCE's types give you enough rope to hang yourself with, to some extent. A C++ compiler would reject an attempt to directly add a std::chrono::time_point and a uint32_t, so the overflow bug couldn't happen using C++14 std::chrono.)