Summary: | draggable objects don't move at the same speed as mouse input | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | court <courthicks1> |
Component: | effects-various | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | bhush94, notmart, plasma-bugs |
Priority: | NOR | ||
Version: | 5.6.0 | ||
Target Milestone: | --- | ||
Platform: | Neon | ||
OS: | Linux | ||
See Also: | https://bugs.kde.org/show_bug.cgi?id=362826 | ||
Latest Commit: | http://commits.kde.org/plasma-integration/3500c766f107d7ab2520c809cbf09f053a6f8062 | Version Fixed In: | 5.7.0 |
Sentry Crash Report: |
Description
court
2016-04-01 22:49:07 UTC
that's because in Qt xcb it seems drag windows are marked as tooltips, that's wrong (tooltip animation KWin effect gets triggered for them) Martin: any idea how to heuristically detect such windows? That's a bug in Qt event handling forgot how to compress events and/or Qt DnD is causing "something™" that is slow on at least the nvidia blob. The problem seem the repaints below (the faster the update, the more obvious the problem becomes, the compositor being a natural trigger but not the problem) https://bugs.kde.org/show_bug.cgi?id=352019#c28 You'll rather not get this problem with DnDs that are NOT Qt5, compositing or the tooltip animation should not matter. *** This bug has been marked as a duplicate of bug 352019 *** I should also note that I was using OpenGL 3.1 for rendering with this The compositor settings won't matter - it's most likely a known problem in Qt. Try to suspend the compositor (SHIFT+Alt+F12), run glxgears and move a drag over the running glxgears window. See what happens. Git commit 3500c766f107d7ab2520c809cbf09f053a6f8062 by Martin Gräßlin. Committed on 14/04/2016 at 08:19. Pushed by graesslin into branch 'master'. add X11Integration for xcb qpa workarounds Summary: this class will collect some adjustments to the xcb qpa make the drag and drop window NOT to be a tooltip. This is a workaround for QtBug https://bugreports.qt.io/browse/QTBUG-52560 FIXED-IN: 5.7.0 Test Plan: Reviewers: graesslin, mart Subscribers: plasma-devel Projects: #plasma Differential Revision: https://phabricator.kde.org/D1402 M +2 -1 CMakeLists.txt M +2 -1 autotests/CMakeLists.txt M +29 -0 autotests/kdeplatformtheme_unittest.cpp M +3 -0 src/platformtheme/CMakeLists.txt M +5 -0 src/platformtheme/kdeplatformtheme.cpp M +2 -0 src/platformtheme/kdeplatformtheme.h A +53 -0 src/platformtheme/x11integration.cpp [License: LGPL (v2/3+eV)] A +40 -0 src/platformtheme/x11integration.h [License: LGPL (v2/3+eV)] http://commits.kde.org/plasma-integration/3500c766f107d7ab2520c809cbf09f053a6f8062 > 3. Remove finger from left-click button to end mouse input on the object being drug > Actual Results: > Icon moves in super slow motion and does not properly follow the mouse This is bug #352019 - altering the type won't help you since the morph ends within 250ms or so anyway. I don't say QTBUG-52560 isn't an *additional* "who cares about desktops" bug in Qt5, but I'd rather not expect this bug to be fixed by a workaround on the window type. @court, run "kcmshell5 kwineffects" and deactivate the "morphing tooltips" effect. Then check whether there's still a problem. @Thomas, I did both of your suggestions and the dragging issue still persists both with system tray icons and folders/files in Dolphin anywhere on the screen and over the glxgears window then the workaround from comment #5 has no impact beause it works around the wrong bug in qt. *** This bug has been marked as a duplicate of bug 352019 *** |