I know Qt shouldn't mark those windows as tooltips, but: When I drag a file eg. in FolderView and I stop moving the mouse with the button still pressed, and I then start moving the mouse, the CrossFadePrevious animation causes the pixmap to fade/flicker, if I disable the fade animation in the effect, this goes away. Reproducible: Always Steps to Reproduce: 1. Enable "morphing popups" effect, enabled by default 2. Start dragging a file 3. While still pressing the mouse button stop moving the mouse and start moving again Actual Results: The drag pixmap flickers/fades briefly Expected Results: The drag pixmap stays as it is
Created attachment 98847 [details] Drag pixmap flicker
> Qt shouldn't mark those windows as tooltips This should be caught by the supposed* fix for bug #361296 by correctly marking the DnD window?** https://bugreports.qt.io/browse/QTBUG-52560 http://commits.kde.org/plasma-integration/3500c766f107d7ab2520c809cbf09f053a6f8062 That aside, it looks like the crossfade happens from an empty texture, ie. the old texture is lost?? --- *the commit cannot fix bug #361296 because qt5 dnd causes something™ t hat's slow at least on nvidia and doesn't drop/compress events, thus the resolution of the bug in contrast to the patch ** though the eventfilter only looks for "inherits("QShapedPixmapWindow")" - could easily fail on QtQtuick
> though the eventfilter only looks for "inherits("QShapedPixmapWindow")" - could easily fail on QtQtuick It also affects Dolphin and the File Open dialog
Hang on, I haven't updated my plasma-integration.
Hooray \o/ Works now in both widgets and QtQuick apps. Doesn't explain the original bug with the supposed fade from empty pixmap though.
Does crossfading work as expected otherwise (eg. maximization effect)? If so, I sense relation to the slow DnD issue (for creating ARGB drawables is still rather slow on nvidia) - the window is probably somehow re-created (or cleared for another reason)
@Kai: given comment #5: is this one RESOLVED WORKSFORME?
Assuming fixed, if not please reopen.