https://bugs.kde.org/show_bug.cgi?id=431652
Bug ID: 431652
Summary: Wayland: multi-monitor zoom effect regression with new
per-output composite-scheduling
Product: kwin
Version: git master
Platform: Gentoo Packages
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: multi-screen
Assignee: kwin-bugs-n...@kde.org
Reporter: 1i5t5.dun...@cox.net
Target Milestone: ---
I'm running git-master kde-frameworks and plasma live-git via the gentoo/kde
overlay live-git packages. Rebuilt today with kwin HEAD currently at
870a9e4d0.
My monitor setup is two 4K 75-inch TVs as monitors arranged horizontally.
Here's my usual monitor/window layout (ASCII-art, best viewed with monospace
font):
| "second" monitor | "primary" monitor |
+-------------------+--------+--------+-+
| | work | work |p|
| full-screen | win2 | win3 |a|
| video +--------+--------+n|
| window | work | work |e|
| | win1 | win4 |l|
+-------------------+--------+--------+-+
As might be imagined two 75-inch TVs wide is a lot of horizontal space so my
focus tends to be toward the (bottom) center.
Sometimes I zoom in and therein is the problem. I'll normally be zooming
work-windows #1 or #2, left side of the right-hand screen/monitor. Often the
zoom places the window on both monitors even tho at normal size it's to the
left on the right-hand monitor.
The problem is that with the new per-monitor composite-scheduling, if I'm
typing and not moving the mouse, the part of the work-window zoomed to the left
monitor doesn't get redrawn to reflect the new content, only the part of the
window on the "home" monitor gets redrawn. As soon as I move the mouse the
part of the window on the left monitor "catches up", but having to constantly
break-flow to switch to the mouse and trigger the repaint is a real work-flow
killer!
(While typing this up I did notice that hitting the zoom hotkey triggers a
repaint as well. I've a keyboard with "extra" keys, three of which are
dedicated zoom-in/out/actual, so that's a nearby single-touch, faster than the
mouse. Another alternative is repositioning the window so a small fraction of
it is on the other monitor at normal size too. Then it updates as it should.)
Obviously the new code doesn't account for the fact that with zoom, a window
appearing on just one monitor at 100%/normal size may appear on the other one
or on both when zoomed in, so the "non-home" monitor isn't getting a redraw
scheduled until the mouse moves.
(Tested konsole gtk3/claws-mail both native wayland, and gtk2/pan, xwayland.
It's the compositor not the app.)
--
You are receiving this mail because:
You are watching all bug changes.
