https://bugs.kde.org/show_bug.cgi?id=499912
--- Comment #8 from cwo <cwo....@posteo.net> --- Created attachment 178557 --> https://bugs.kde.org/attachment.cgi?id=178557&action=edit four consecutive frames from a screen recording (In reply to Nate Graham from comment #7) > The other issues are not really fixable without a transition between them, > which was explicitly removed because it caused even worse glitches. Are you sure that's the only way? The content gets updated before the size of the popup, which causes much of the glitchy look. Going back to morphing popups is probably a bad idea, but if we can go from content updates, gets painted in the wrong spot as there's not enough space -> popup size updates, gets painted -> content gets painted correctly to content updates does not get painted yet -> popup size updates -> content gets painted correctly it should look a lot cleaner, even if the popup might appear a frame later. And without having attempted it (but having looked at that area of the code recently) I think it should be possible - we could intercept the maintext/subtext changes, calculate or at least approximate the size, then set the item's implicit sizes before actually putting the content in. It won't be quite as smooth as morphing popups was in the cases when it worked, but just avoiding things like in the screenshot should make it look much better. I think it at least could work, unless I'm missing something. -- You are receiving this mail because: You are watching all bug changes.
