Bug 370634 - Present windows lags dramatically when mouse is on the second monitor
Summary: Present windows lags dramatically when mouse is on the second monitor
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: effects-present-windows (show other bugs)
Version: 5.8.0
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-10-13 10:34 UTC by Marco Silva
Modified: 2021-12-06 04:38 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marco Silva 2016-10-13 10:34:50 UTC
I'm on a multi-monitor setup with 2 monitors.
I open Present Windows, then I move the mouse from my primary monitor to the secondary, Present Windows starts to drag and only refreshes @ 1 frame / second.
If I filter by text, and the resulting window is on the secondary monitor, it also lags.
Note: lag is observed on both monitors.

i7 3rd gen w/intel xf86-video-intel drivers.

Reproducible: Always

Steps to Reproduce:
1. I'm on a multi-monitor setup with 2 monitors.
2. I open Present Windows.
3. Then I move the mouse from my primary monitor to the secondary.

Actual Results:  
Present Windows starts to drag.

Expected Results:  
Keep it fluid and smooth without lagging.
Comment 1 Marco Silva 2016-10-13 10:49:20 UTC
A way to always reproduce it:
1. Have a 2 monitor setup and some windows on both.
2. Open KDE Present Windows.
3. Move mouse from primary monitor to secondary. If Preview Windows it is not lagging already, move mouse back to primary and again to secondary monitor.
Comment 2 Martin Flöser 2016-10-13 11:14:05 UTC
Please try the modesettings driver for xorg. I'm quite sure it will fix the issue.
Comment 3 Marco Silva 2016-10-13 13:28:05 UTC
Correction: I am NOT using xf86-video-intel.

Specifically:
xf86-video-intel 1:2.99.917+711+gbd33d0a-1 (xorg-drivers xorg)
    X.org Intel i810/i830/i915/945G/G965+ video drivers
this package is NOT installed in my Arch.
Comment 4 Martin Flöser 2016-10-13 14:28:04 UTC
that's the first time in month that didn't help...

Can you check top for high cpu usage?
Comment 5 Marco Silva 2016-10-13 14:44:47 UTC
Yes.
With Present Windows opened, and moving the mouse from one monitor to the other, in htop I can see kwin as the top process using the CPU. The usage is around 5-6% on an intel i7 (3rd gen).

The lagging stops itself after around 3 seconds, but I can see that windows highlighting or raising is a tidy bit slower in FPS after the lag finishes. CPU usage in kwin returns to the normal 2-3% after that.
Comment 6 Martin Flöser 2016-10-13 15:40:25 UTC
on the other hand 5-6 % cpu usage is not so much that it would explain a blocking of mouse movement.
Comment 7 Marco Silva 2016-10-13 15:51:51 UTC
Another colleague replicated in his Fedora with 5.8 LTS.
On his i7 (4rd gen), the lag happens only for 1 second, but it's still noticeable.

He has xorg-x11-drv-intel installed with SNA enabled.
Comment 8 kde.org 2021-11-06 17:52:56 UTC
This issue report is quite old. Can you please confirm, that it still persists with KDE 5.23?
Comment 9 Bug Janitor Service 2021-11-21 04:39:29 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 10 Bug Janitor Service 2021-12-06 04:38:51 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!