It's not a bug, it's a feature :)
When tooltip changes, two things happens:
* content changes
* then size is animated
As a result, in some cases the effect is ugly if size difference is significant.

Any idea how it should behave?

The effect looks laggy. It's not possible to improve it?

Maybe. If we get the resize and the contents atomically we should be able to blend in the contents. We do that for one of the other kwin resize effects.

Does someone want to test:

diff --git a/effects/morphingpopups/package/contents/code/morphingpopups.js b/effects/morphingpopups/package/contents/code/morphingpopups.js
index 838964f6e..f862af948 100644
--- a/effects/morphingpopups/package/contents/code/morphingpopups.js
+++ b/effects/morphingpopups/package/contents/code/morphingpopups.js
@@ -115,7 +115,7 @@ var morphingEffect = {
             couldRetarget = retarget(window.fadeAnimation[0], 1.0, morphingEffect.duration);
         }
 
-        if (!couldRetarget) {
+        if (true) {
             window.fadeAnimation = animate({
                 window: window,
                 duration: morphingEffect.duration,





you should be able to mod morphingpopups.js within your installation without needing to rebuild kwin

David, I added your code to morphingpopups.js and ran "kwin_x11 --replace" but nothing changed.

Can reproduce with Task Manager tooltips too.

Created attachment 130134 [details]
Seen with Task Manager tooltips

Moving to KWin since it seems to be an issus with the Morphing Popups effect.

*** Bug 427193 has been marked as a duplicate of this bug. ***

I don't think that we can (properly) fix this bug without changing the client side. Basically, plasmashell will have to perform a "live resize" (like on macOS) on tooltips.

is bug 427127 a duplicate?

Pretty sure, yeah.

*** This bug has been marked as a duplicate of bug 427127 ***

Since this bug is the older one and contains more information, I am reversing the duplicate direction.

*** Bug 427127 has been marked as a duplicate of this bug. ***

Just to confirm, this only happens on Wayland as on the duplicate, correct?

*** Bug 432255 has been marked as a duplicate of this bug. ***

Mh, looking at the videos here, the symptoms look different compared to https://bugs.kde.org/show_bug.cgi?id=427127 (and this here seems to also happen on X11). So I am not entirely sure whether that one is actually a duplicate of this.

*** Bug 433792 has been marked as a duplicate of this bug. ***

*** Bug 403321 has been marked as a duplicate of this bug. ***

*** Bug 437789 has been marked as a duplicate of this bug. ***

*** Bug 439120 has been marked as a duplicate of this bug. ***

I'm getting the same issue when moving the mouse across the taskbar. And worse yet, I can end up with remnants of glitched tooltips on-screen, not cleared when you move the mouse away (https://bugs.kde.org/attachment.cgi?id=140014, see 0:12).

I was also able to create a black graphical corruption on the left side of the screen that flickered when I moved my mouse across the icons on the right of the panel, but I was unable to record or reproduce that issue, and it disappeared before I could launch a screen recorder. I did manage to record a video of a corrupted tooltip icon, rendering in the wrong spot, scaled up from its original size, and flickering (https://www.youtube.com/watch?v=uicwjFR3du8).

Created attachment 141286 [details]
Flickering tooltips with lattedock

I've witnessed this bug in a more gross form with lattedock tooltips (see attachment).

*** Bug 443753 has been marked as a duplicate of this bug. ***

*** Bug 443938 has been marked as a duplicate of this bug. ***

*** Bug 444819 has been marked as a duplicate of this bug. ***

*** Bug 445080 has been marked as a duplicate of this bug. ***

what happens in this bug is that whe window contents are replaced immediately rather than cross faded like the maximize effect (ar what this effect used to do)

Here not only morphingpopup shows this, but also maximize and fullscreen show the same glitch (very noticeable if one sets animations to be super slow) so seems crossfading got completely broken on kwin effects

Cross fading support was recently removed as part of the scene redesign work, will eventually get back reimplemented properly

Bug 305247 was just fixed yesterday in git master and now I can no longer reproduce the issue here. Can anyone running git master everything check as well?

it's still reproducible on neon unstable.

OK.

*** Bug 446327 has been marked as a duplicate of this bug. ***

*** Bug 448561 has been marked as a duplicate of this bug. ***

*** Bug 448950 has been marked as a duplicate of this bug. ***

*** Bug 448312 has been marked as a duplicate of this bug. ***

*** Bug 453834 has been marked as a duplicate of this bug. ***

Created attachment 148861 [details]
Tooltip flickering when resizing from a window preview and a smaller tooltip

*** Bug 461632 has been marked as a duplicate of this bug. ***

I found very related bug in other part of KDE: Kirigami and Plasma Icons. They are QML components, and they are supposed to cross-fade when changed. But due to the way they work, they assume before & after sizes are equal, so when transitioning between e.g. rectangular and square icons, the animation isn't smooth at all. Attempt to fix that uncovered another corner case: transitioning from the middle of an ongoing transition, which as turned out required manual blending with QPainter and stuff.

Different area, but very similar problem. Quite likely, they'll be both fixed in the same way.

*** Bug 470463 has been marked as a duplicate of this bug. ***

A good test is qtbase/examples/widgets/widgets/tooltips

*** Bug 471360 has been marked as a duplicate of this bug. ***

*** Bug 473411 has been marked as a duplicate of this bug. ***

(In reply to Nate Graham from comment #46)
> *** Bug 473411 has been marked as a duplicate of this bug. ***

Hi Nate, my bug is different. I have no problem with plasma things like panel, etc. only on QTwidgets.

I add my video here too.

Created attachment 161096 [details]
QT tootips corruption

I would like to try to exclude QTWidgets tooltips from the effect. Looking at the documentation here (https://techbase.kde.org/Development/Tutorials/KWin/Effects/JS_API) I understand that there is no property to distinguish. On the other hand looking at the fadindpopups effect I see that there is a window.popupWindow property that is not documented, so I would need to know if there is a property like window.QTWidgetTooltip or window.QMLTooltip that would allow to distinguish between tooltips types.

*** Bug 477998 has been marked as a duplicate of this bug. ***

(In reply to David Edmundson from comment #4)
> Does someone want to test:
> 
> diff --git a/effects/morphingpopups/package/contents/code/morphingpopups.js
> b/effects/morphingpopups/package/contents/code/morphingpopups.js
> index 838964f6e..f862af948 100644
> --- a/effects/morphingpopups/package/contents/code/morphingpopups.js
> +++ b/effects/morphingpopups/package/contents/code/morphingpopups.js
> @@ -115,7 +115,7 @@ var morphingEffect = {
>              couldRetarget = retarget(window.fadeAnimation[0], 1.0,
> morphingEffect.duration);
>          }
>  
> -        if (!couldRetarget) {
> +        if (true) {
>              window.fadeAnimation = animate({
>                  window: window,
>                  duration: morphingEffect.duration,
> 
> 
> 
> 
> 
> you should be able to mod morphingpopups.js within your installation without
> needing to rebuild kwin

For me this fixes the issue somewhat -- without the patch morphing tooltips often end up in a broken state, with some of the content cut off; with the patch the tooltip always end up with the correct size, though the animations can be a bit glitchy.

I can reproduce that that patch makes a big difference. Since we know there are client-side bugs here, maybe that or that plus a little something extra might be enough to call this fixed from a KWin perspective.

The patch doesn't solve the problem with QTWidget Tooltips

Right, because the bug isn't about QtWidgets tooltips. The Morphing Popups effect doesn't apply to them.

(In reply to Nate Graham from comment #54)
> Right, because the bug isn't about QtWidgets tooltips. 

I am writing here because the bug I had opened was closed because it was considered a duplicate of this one.

> The Morphing Popups
> effect doesn't apply to them.

Are you sure? When I enable the effect the problem with QTWidgets occurs, when it is disabled it does not.

Hmm, well I was, but now I'm not anymore!