Bug 352019

Created attachment 94287 [details]
qdbus org.kde.KWin /KWin supportInformation

- is eg. moving windows equally slow?
- does maybe simply restarting the compositor (w/o changing the backend) help as well?
> Painting blocks for vertical retrace:  no
Though not directly related, what's the output of "grep -i triple /var/log/Xorg.0.log"?

- moving windows is fast, as usual
- kwin_x11 --replace or toggling with shift+alt+f12 doesn't do anything
- output for "grep -i triple /var/log/Xorg.0.log" was empty, but after I added the TrippleBuffer option trying to get fluid mpv playback it changed to:
[     4.405] (**) NVIDIA(0): Option "TripleBuffer"

Issue still persists though.

Make that "[     4.378] (**) NVIDIA(0): Option "TripleBuffer" "True"", noticed I forgot to add the "True" part. There is a slight improvement with 5.4.0, but 5.3.2 is now less responsive.

Ok, since windows move as expected and also the display updates in other regions, it's not kwin or the driver lagging frames; we must assume that the client has indeed trouble to reposition the item.

The only "interaction" with kwin I could atm. think of is KWIN_EXPLICIT_SYNC.

- Did you also test the impact of "export KWIN_EXPLICIT_SYNC=0" on this?
- How's CPU load while dragging those items?


https://forum.kde.org/viewtopic.php?f=111&t=128058

- export KWIN_EXPLICIT_SYNC=0 makes things even better, but still lagging
- CPU usage is about 36% on an AMD X4 970BE@3.5GHz, it only uses the 2.65GHz clock rate at most, though. Highest offender is xorg with ~22%, followed by dolphin ~6% and kwin ~5%

It seems that moving on a straight line has the least impact, but any curved movement makes it lag very badly.

Is this KF/5 dolphin and in case: does dragging items from some Qt4/KDE4 application (kdebase-konqueror uses the KDE4 dolphinpart) lag as well?

It's not just dolphin, but yes, kf5
And yes, konqueror doesn't lag, the item sticks to the cursor at all times.

This smells like some problem in Qt5 input handling in the client (dolphin) like it queues the mouse movements and then handles them one-by-one, with far too much delay between the individual events (instead of eg. dropping all events but the last)

(The alternative of KWin handling unmanaged geometry changes too slow would affect the KDE4 drags likewise)

The "did not happen in 5.3.2" claim may be a red herring then (for arch shipped dolphin/4 at that time)?

The "far too much delay" will be caused by some opengl/x11/xcb collision, but don't ask me what.
Do you use xf86-input-evdev or xf86-input-libinput as mouse driver?

> The "did not happen in 5.3.2" claim may be a red herring then (for arch shipped dolphin/4 at that time)?

Yes, arch shipped dolphin/4 (15.04) at that time. However, I don't remember dragging widgets to the desktop be affected before 5.4, so maybe it's valid after all?

> Do you use xf86-input-evdev or xf86-input-libinput as mouse driver?

xf86-input-evdev, according to pacman.

I've the same problem: openSUSE 13.2 with Plasma 5.4 and KDE applications 15.08
With former release (Plasma 5.3 and KDE applications 15.04) it worked smooth as Soukyuu described it.
I also have a nvidia card with proprietary drivers installed.

Which nvidia driver (I'm, on 352.30)
Random guess: Do you use a mouse or a touchpad?

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

This happens also in Teamspeak3 etc. Installed Gnome Classic and I could drag icons fast again so its something in KF5 that affects pretty much every application.

I also noticed that if you toggle compositing off it also happens sometimes when dragging Windows. 

Also updated link to video: http://galactica.no-ip.org/index.php/s/6aYCybuQBmXQuXU
(had expiration date set)

Created attachment 94371 [details]
qdbus org.kde.KWin /KWin supportInformation output

Also forgot, this happens with mouse.
(In gnome classic i only tested dragging the desktop icons)

> You are correct, disabling compositing also shows this when moving windows. Im confused about this.

I'd say there's a problem with xcb event processing in Qt5 applications (ie. they receive the mouse event too late)
It's weird though that this affects either uncomposited KWin or composited DnD.

Arch has few updates for me in the pipeline - let's see what happens ;-)

(In reply to Thomas Lübking from comment #12)
> Which nvidia driver (I'm, on 352.30)
> Random guess: Do you use a mouse or a touchpad?

nvidia driver 340.76 (I think latest one for 9XXX series...)
I'm using a mouse but touchpad is activated in parallel.

Nope, no lagging here :-(

(In reply to alfaflo from comment #17)
> (In reply to Thomas Lübking from comment #12)
> > Which nvidia driver (I'm, on 352.30)
> > Random guess: Do you use a mouse or a touchpad?
> 
> nvidia driver 340.76 (I think latest one for 9XXX series...)
> I'm using a mouse but touchpad is activated in parallel.

Hello Thomas

I've tried the integrated touch pad and there is no lag - the icons "follow" the cursor instantly. Problem only exists using the mouse (Logitech G400 optical mouse)...

A-ha!

Wild guess #2 - can you lower (or just alter) the resolution of that device?
(try https://wiki.archlinux.org/index.php/Lomoco if it doesn't have a HW button)

----
So let's record our rodents:
Me never dropped my Logitech MX500 (and yes: it is from 2002 or so) but also tried a broken MS-Tech crapdevice (the wheel survived ~1 month *lol*) and neither get that problem.

I'm using a Revoltec FightMouse Elite (*rolls eyes at the name* the mouse itself is great, never getting a non-ceramic feet mous ever again). It has a hardware switch for dpi, but going from highest to lowest doesn't change the behavior for me.

Just guessing, but since you seem to not be getting the issue, maybe our cards (260GTX, alfaflo's 9 series) display this issue because they're older and some sort of operation is horribly inefficient on them?

Well, this is interesting. Just tried an old Logitech V550 (no dpi switch) and it doesn't show the behavior! So it might be related to resolution... but why is it only a problem in kf5?

More like a problem how either Qt5 or libinput or evdev (or the chain) handles high resolution mouse input events. (The GPU doesn't matter, KWin is perfectly up-to-date on frames - or at least not that horribly lazy)

What might be interesting is the uncomposited lag in KWin - the window isn't actually moved until you release it when the compositor is up (we only reposition the texture and avoid X11 since that's n-times faster)
So it might be indeed a problem with "too many events" in the X11 event queue (causing problems when having to reposition an actual window; the client, ie. dolphin or kwin for windows, still gets all events in time and as expected)

Can you alter the resolution of your mouse? (lomoco is afaik only for logitech)
Or did maybe the xinput manipulation (when plugging in the device) alone "fix it" and now it works with your elitist rodent as well?

(In reply to Thomas Lübking from comment #23)
> More like a problem how either Qt5 or libinput or evdev (or the chain)
> handles high resolution mouse input events. (The GPU doesn't matter, KWin is
> perfectly up-to-date on frames - or at least not that horribly lazy)
> 
> What might be interesting is the uncomposited lag in KWin - the window isn't
> actually moved until you release it when the compositor is up (we only
> reposition the texture and avoid X11 since that's n-times faster)
> So it might be indeed a problem with "too many events" in the X11 event
> queue (causing problems when having to reposition an actual window; the
> client, ie. dolphin or kwin for windows, still gets all events in time and
> as expected)
> 
> Can you alter the resolution of your mouse? (lomoco is afaik only for
> logitech)
> Or did maybe the xinput manipulation (when plugging in the device) alone
> "fix it" and now it works with your elitist rodent as well?
More likely a QT issue then since I can launch dolphin4 in arch and not experience the issue at all. While having Dolphin from KF5 running at the same time and have this issue.

And does your Qt4 use libinput or xcb?
(Be warned that I'm on Archlinux as well - I know the answer ;-)


What's clear is that despite the GL compositor is somehow™ a trigger for DnD lagginess, the bug won't be in either Dolphin or KWin, but somewhere int Qt5 and its dependencies.

Do you recall whether this already happened with Qt 5.4?

> Or did maybe the xinput manipulation (when plugging in the device) alone "fix it" and now it works with your elitist rodent as well?
My elitist rodent still behaves as before, and there doesn't seem to be a way to change it otherwise that I know of.

> Do you recall whether this already happened with Qt 5.4?
I did use to compile dolphin-git pre-Qt 5.5 and I don't remember such issues.

(In reply to Thomas Lübking from comment #20)
> A-ha!
> 
> Wild guess #2 - can you lower (or just alter) the resolution of that device?
> (try https://wiki.archlinux.org/index.php/Lomoco if it doesn't have a HW
> button)
> 
lomoco doesn't support my Logitech mouse but I've tried another one (Logitech M325 cordless) and I drag'n drop works fine. So it's definitive related to specific input devices... (at least at my system)

Gotcha!

One needs a high frequency repainting OpenGL client (some plasmoids tend to do that, cpu graph et al - figured when running glxgears) and dragging lags.

W/o compositing, it's only notable when dragging "something" across the GL view (in my case a DnD icon across glxgears), but with GL compositing, you're always dragging something across *the* GL view (being the compositor)

Indeed only Qt5 drags are affected, dolphinpart-4 (still used in konqueror) is lag-free.

=> I can confirm the bug, but it's between the nvidia driver and Qt5 for sure.

No idea how the input devices come to play in addition, but at least it's now reproducible >-)

I'm getting gradually weary of having an nvidia card, especially a legacy one because if it's really a driver problem, then it won't be fixed anymore. Any chance for some workaround?

Certainly not from KWin ("how?"), but since only Qt5 seems affected, it should be addressable there.

Actually my previous description was wrong, though:
- it *only* lags *above* a high frequency repainting areas
- the graphics context below is irrelevant (tried pong from xscreensaver, no GL, as well as VDPAU video overlay)
- it seems completely irrelevant whether I've an (opengl) compositor enabled or not (it's still *only* lagging above the high frequency update window in either case)

Also i can "openbox --replace&" and get the very same behavior (Qt5 DnD lags above glxgears/mplayer)

PS: CPU is fully loaded and distributed between dolphin and X11 (when compositing, a *bit* more KWin as well, but it's clearly limited between X11 and dolphin)

(In reply to Thomas Lübking from comment #30)
> Certainly not from KWin ("how?"), but since only Qt5 seems affected, it
> should be addressable there.

Thank you Thomas for creating a new Qt bug-report. :-)

Btw, I just tested with nouveau and it doesn't have the problem except when draging a pixmap over a title bar of a window...

So it's Nvidia issue that QT triggers? How do we proceed, should we post on their dev forums? Just tried latest beta driver 358.09 and the issue is still there.

Also forgot to add; tested with another mouse found it interesting. 

Using Logitech G9x 1000Hz and the result is the video I posted.
Using Microsoft BT nano mouse it does not show that _until_ i drag the icon over Steam window when it's showing my Library, or as someone else reported when hovering over title-bars, tabs in chromium etc.

Please see the referenced https://bugreports.qt.io/browse/QTBUG-48122

I'm experiencing lag on drag and drop on dolphin and between kde apps, like from dolphin to kate. Moreover the big lag is when I try to move "qmmp" window. The window needs about 5 to 10 seconds to be repainted on the new position.

( intel i7 4770k, logitech m500, nvidia gtx 660 with current archlinux packages )

latest update (plasma 5.6 & qt 5.6) fixed it for me
by the way: plasma is now smooth like never before - thanks guys!

florian

(In reply to alfaflo from comment #38)
> latest update (plasma 5.6 & qt 5.6) fixed it for me
> by the way: plasma is now smooth like never before - thanks guys!
> 
> florian

(In reply to Thomas Lübking from comment #36)
> Please see the referenced https://bugreports.qt.io/browse/QTBUG-48122

I can confirm this also. After Arch updated to QT 5.6 and Plasma 5.6 with the rest the issue is now fixed for me too.

Looking at https://bugreports.qt.io/browse/QTBUG-48122 it seems it's not related to this issue or that it was somehow fixed by another issue in QT and that 48122 was not the "leading" cause of the lag.

(In reply to alfaflo from comment #38)
> latest update (plasma 5.6 & qt 5.6) fixed it for me
> by the way: plasma is now smooth like never before - thanks guys!
> 
> florian

An additional note: it seems that it's not fully gone. Compared to using noveau there's still a (very) little  "lag" but I think for daily use it's not a problem.

(In reply to alfaflo from comment #38)
> latest update (plasma 5.6 & qt 5.6) fixed it for me
> by the way: plasma is now smooth like never before - thanks guys!
> 
> florian

An additional note: it seems that it's not fully gone. Compared to using noveau there's still a (very) little  "lag" but I think for daily use it's not a problem.

(In reply to alfaflo from comment #41)
> (In reply to alfaflo from comment #38)
> > latest update (plasma 5.6 & qt 5.6) fixed it for me
> > by the way: plasma is now smooth like never before - thanks guys!
> > 
> > florian
> 
> An additional note: it seems that it's not fully gone. Compared to using
> noveau there's still a (very) little  "lag" but I think for daily use it's
> not a problem.

Do you mean the slight lag of like couple pixels? About the same as Window drag?

> Do you mean the slight lag of like couple pixels? About the same as Window
> drag?
Yes, just a couple of pixels. A few days ago I've tested nouveau and noticed no "lag" but as 3D performance is "non-existent", I've switched back to proprietary driver :-)

it's important to check the behavior over animated content (drag it across an unsynced glxgears) - the everyday nastiness could be mitigated by a less updating desktop window (removed animations in indicators etc)

didn't try, though

(In reply to Thomas Lübking from comment #44)
> it's important to check the behavior over animated content (drag it across
> an unsynced glxgears) - the everyday nastiness could be mitigated by a less
> updating desktop window (removed animations in indicators etc)
> 
> didn't try, though

hm... "lag" gets bigger if I drag an icon over glxgears but still much better than in plasma <5.6.
So it's not fixed but at least it doesn't prevent useful drag'n drop.

(In reply to Thomas Lübking from comment #44)
> it's important to check the behavior over animated content (drag it across
> an unsynced glxgears) - the everyday nastiness could be mitigated by a less
> updating desktop window (removed animations in indicators etc)
> 
> didn't try, though

(In reply to alfaflo from comment #45)
> (In reply to Thomas Lübking from comment #44)
> > it's important to check the behavior over animated content (drag it across
> > an unsynced glxgears) - the everyday nastiness could be mitigated by a less
> > updating desktop window (removed animations in indicators etc)
> > 
> > didn't try, though
> 
> hm... "lag" gets bigger if I drag an icon over glxgears but still much
> better than in plasma <5.6.
> So it's not fixed but at least it doesn't prevent useful drag'n drop.
Well this is weird.
For me, lag gets quite bigger just by having glxgears open on the desktop (not as much as before 5.6 but noticeable. 
No actual change if I drag over the glx window or if I minimize the glxgears window. 

Still having the same mouse, and reducing the polling rate to 250MHz from 1000MHz and no lag is noticeable again no matter if I got glxgears open or not.

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

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

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

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