https://bugs.kde.org/show_bug.cgi?id=487563
pallaswept <pallasw...@proton.me> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pallasw...@proton.me
--- Comment #3 from pallaswept <pallasw...@proton.me> ---
This issue seems very widespread. I'm suffering it myself so I notice the
multiple posts on reddit per day about it. But I also noticed the issue is
misunderstood as a VRR-related one, and that 'auto' VRR resolves it. It does
not.
The issue is not only that the cursor drops to minimum FPS with VRR enabled -
even with adaptive sync set to "auto", even with it disabled, we can see the
cursor being faulty. If you need it, I'll get a photograph, since a screenshot
won't catch it, but if you want to see this, just take your mouse, and drag it
in a line across your display.
What you should see, courtesy of pixel response times leaving behind ghosts of
the previous frames, is a line of cursors, evenly spaced, like so:
x x x x x x x x x x x x x x x x
What you will see instead, is a broken line of cursors, like so:
x x x x x x x x x x x x x x x
x
If this isn't hanging around on screen long enough just move the mouse in
circles. Instead of seeing a nice evenly spaced 'polygon' of pointers, you'll
see them clumped together - or you'll notice the 'breaks' in the circle of
cursors. For me, the pattern I can see on screen is 3 pointers, then a gap,
like `x x x x x x x x x ` The most number of these 'breaks' we should ever
be able to see, if the cursor movement is consistently drawn, is one - after
the least recent one (in other words, at the end).
My point is, there is clearly a general problem with the drawing of the cursor,
specifically the timing of it, in Plasma right now. VRR exposes it in an
extreme and un-missable way because it drops the cursor FPS so low that it
becomes difficult to use it as a pointing device. But the issue of timing
problems with the cursor, is present, always, VRR or no.
> The cursor refresh rate is intentionally dropped to the content, to prevent
> the content stuttering...
I guess the problem here is that this design does not account for the cursor
being the only 'content', and allow it to be displayed at the set refresh rate
of the monitor.... but anyway, I'm not sure that's the root of the cursor
problems we can see... at least, not by itself.
Of course, maybe these are two separate issues, one effecting VRR and one
effecting everything including VRR, but since the behaviour is inseparable, I
couldn't assume that without having seen the code that causes the bug.
--
You are receiving this mail because:
You are watching all bug changes.
