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

Pedro V <voidpointertonull+bugskde...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |voidpointertonull+bugskdeor
                   |                            |g...@gmail.com

--- Comment #8 from Pedro V <voidpointertonull+bugskde...@gmail.com> ---
It's rather odd to see this issue to be known for so long while there's
apparently still no fix. Somewhat ironically Krusader introduced me to this
problem as doing heavy operations there like synchronizing directories and
moving the cursor over the window was a guaranteed way to lose progress.

Also, I find the "RESOLVED UPSTREAM" status quite amusing. Took it registering
here to see that it apparently means that it's resolved as being an upstream
problem which is quite unfortunate. Status display could use some improvement.

Is it not feasible though to at least throw in a workaround? Upstream doesn't
seem to be too interested in fixing yet, even though the buffer seems to be
tiny, and expecting the other side to just "simply" keep up on a non-realtime
system appears to be bad design, given that regardless of buffer size, the
possibility of programs just not getting scheduled in time is always around, so
not tolerating a buffer full state practically guarantees a race condition.

A significantly larger buffer could already help a lot by not punishing at
least a single pass of moving the cursor over busy windows so at least people
aware of the issue could have an easier time avoiding the problem.
Also, it seems like GNOME stopped waiting for upstream a while ago already:
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2122

I believe it's a common enough issue to deserve more attention, at least I've
ran into the issue often enough. It was especially bad on a laptop under heavy
I/O pressure which lead to this problem quite often. Life is better with a more
powerful desktop so far, and apparently Krusader stays responsive during
synchronization nowadays, but currently Firefox taps out every few days aside
of mystery issues which may or may not be related, and I know that with the
issue being a design flaw causing a race condition, it will be never gone
without a fix.

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

Reply via email to