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!

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5861

Git commit d6360cc4ce4e0d85862a4bb077b8b3dc55cd74a7 by David Edmundson.
Committed on 11/06/2024 at 19:58.
Pushed by davidedmundson into branch 'master'.

effects: Drop morphing popups effect

The effect does not work very well for two main reasons:
Some clients will make a new popup rather than move an existing one, so
whether it does anything is highly unpredictable as a user.

Popups can be of massively different sizes with different amounts of
text. This means the text in the smaller popup gets resized which
doesn't look like a natural in-between state of the two popups. This
defeats the objective of looking smoother.

On top of that, it's rather glitchy.
This effect was purely visual, no functionality changes.
Related: bug 473411, bug 466638, bug 461501, bug 466637

M  +0    -1    src/plugins/CMakeLists.txt
D  +0    -1    src/plugins/morphingpopups/CMakeLists.txt
D  +0    -137  src/plugins/morphingpopups/package/contents/code/main.js
D  +0    -144  src/plugins/morphingpopups/package/metadata.json

https://invent.kde.org/plasma/kwin/-/commit/d6360cc4ce4e0d85862a4bb077b8b3dc55cd74a7

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

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

While I do agree that was a duplicate for the morphing part of the issue, there's still the matter of the other odd tooltip rendering issue. I'll add an attachment to showcase it, it specifically, but I'm expecting it's going to warrant a different report if it has not already been reported.

Created attachment 170776 [details]
Probably unrelated tooltip corruption

That's something different, yeah. If it's 100% reproducible with Plasma 6.1.1, please do open a new bug report for it. Thanks!