<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO --- - KDE Konsole very slow scrolling with TearFree and QT graphics system native" href="https://bugs.freedesktop.org/show_bug.cgi?id=77436#c128">Comment # 128</a> on <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO --- - KDE Konsole very slow scrolling with TearFree and QT graphics system native" href="https://bugs.freedesktop.org/show_bug.cgi?id=77436">bug 77436</a> from <a class="email" href="mailto:chris@chris-wilson.co.uk" title="Chris Wilson <chris@chris-wilson.co.uk>"> Chris Wilson</a> <pre>It's a balance between render lag and input lag. If we forgo throttling, we can build long streams of render commands on the GPU, and the display lags behind. If we wait for the GPU for too long, we stop sending clients updates. I have two problems here: 1. The throttling should already exist to prevent the huge +2s stalls. Unless it is just a single massive batch constructed within one throttle period that generates the massive stall. trace-cmd should help identify if that is the case. 2. There is no way that we should be able to queue more than the GPU can handle in the first place, certainly not +2s! So something is not quite right with the command stream. This is why I have been trying to spot likely culprits such as using large untiled buffers.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>