https://bugs.kde.org/show_bug.cgi?id=489862

Tom Dzmelyk <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|[email protected]         |[email protected]
   Target Milestone|1.0                         |---
            Product|plasmashell                 |kwin
          Component|general                     |general

--- Comment #16 from Tom Dzmelyk <[email protected]> ---
I believe I've chased this down.

The super noticeable stuck on edge behavior was a regression introduced by this
commit:
https://invent.kde.org/plasma/kwin/-/commit/31e0e256ad534c146bd42a6ad3c22bdc16d56685
.

That is fixed now, but only in 6.4 by
https://invent.kde.org/plasma/kwin/-/commit/64eb6cab7e9c88940a6743cd476640b5b3008b9b
.

Backporting that commit to 6.3 fixed 99.9 percent of the issue for me but I
could still produced stickiness on slow movements. I easily reproduced this by
doing steep diagonal inputs.

The last 0.1% is that Workspace::outputAt() assumes a that the screen layout is
contiguous, but for certain resolution and render scales Kwin isn't generating
a contiguous layout. At 1440p and 120% resolution scale for dual monitors
side-by-side it creates QRectF(0,0 2133x1200) and QRectF(2134,0 2133x1200),
which leaves a one pixel gap between outputs. At 125% render scale it generates
QRectF(0,0 2048x1152)  and QRectF(2048,0 2048x1152) which is contiguous.

Some logging I hacked to Workspace::outputAt() confirmed this.

pos  QPointF(2133,904.333)
Geometry:  QRectF(0,0 2133x1200)    Output Distance:  1
Geometry:  QRectF(2134,0 2133x1200)    Output Distance:  1

Which explains the behavior I was seeing, whichever monitor is iterated over
first wins. Moving from plasmashell to kwin so the right people get their eyes
on it.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to