https://bugs.kde.org/show_bug.cgi?id=484819
phantomsh...@proton.me changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |phantomsh...@proton.me
--- Comment #4 from phantomsh...@proton.me ---
I believe the initial report is related to an older bug report which is still
in fact waiting to be resolved upstream in Firefox's 128 release, where mouse
movement causes the screen share to stutter due to cursor metadata being
processed.
https://bugs.kde.org/show_bug.cgi?id=486081
(Until Firefox/Chromium release the relevant version in which the fix is
implemented in WebRTC, I'm currently using a very lightly patched version of
kwin gets around the issue which is why I don't comment on it in the second
half of this comment).
The second report, on the other hand, brings to light a new issue specific to
kwin (as noted here and in this comment
https://github.com/Vencord/Vesktop/issues/629#issuecomment-2186671650) which I
have reproduced myself through base chromium as well as the app they used.
The observed behavior is that if there is no cursor movement over the region
that is being casted, the screen share will have a very low framerate, whereas
if there IS cursor movement, the screen share will be completely smooth. As
noted, "shaking the cursor" also seems to cause the issue, although this is
because as of 6.1 shaking the cursor causes it to expand to make it easier to
find, but this has the side effect of hiding the cursor from being captured
(for example, it cannot be captured by spectacle), which is in effect making
the cursor not move. The same effect is observed in the gameplay since as a
first-person game the cursor itself never moves.
I add the additional detail that this problem only seems to occur on Chromium,
as Firefox is capturing things just fine regardless of mouse movement.
--
You are receiving this mail because:
You are watching all bug changes.
