https://bugs.kde.org/show_bug.cgi?id=489952
pallaswept <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDSINFO |CONFIRMED Resolution|WAITINGFORINFO |--- Ever confirmed|0 |1 --- Comment #37 from pallaswept <[email protected]> --- Tracing this was really interesting this time. I found a perfect demo. Moving the mouse over the desktop 'drops frames' (quotes because I have no idea what to really call this) Moving the mouse over konsole is the same Moving the mouse over firefox the mouse looks normal As discussed above, my firefox profile animates the browser for a few seconds, which keeps the cursor happy. So I made konsole transparent, so I could do the traces with firefox in the background still rendered through the konsole window. I started the trace, alt-tabbed to firefox to kick off the animation timers, alt-tabbed back to konsole so firefox would time out, do it's animation, and then stop. Meanwhile I just moved the mouse in figure-8s over konsole. After the timers end, the animation runs, they end and the cursor goes bad, I let it run a couple seconds and stop the trace. This way there's a clean 'cut' between 'working, because firefox is doing stuff' to 'busted because firefox stopped doing stuff', but nothing else has changed, there was no switching active app or anything like that, just me, movin the mouse in 8's over the same window. Attached is an image of that moment in GPUview. I have filtered for the vblank events. This is a 60Hz HDMI TV, so they should be 16.667ms apart. While firefox is animating, this is the case. The moment that firefox stops animating and goes idle, the cursor goes bad, and the vblank events are now 14.4ms apart and growing. Occasionally, the vblank events are handled differently (by nvidia-modeset, as it was when firefox was animating, rather than this thread named after the device (what is that?)) and those arrive on time (even rounding for the error of the previous frame) . I see about 6 per second here, which seems about right? for how many 'dropped frames' we see in the cursor. Once one of those events is correctly spaced at ~16.66ms, nvidia-modeset stops handling the vblanks again and it switches back to the monitor-thread-thing, drifts a while, until nvidia-modeset tries again. zamundaaa, does this mean anything to you? It seems to me as though there are two processes which can handle those vblank events and one of them has this timing problem and occasionally the modeset driver kicks in to try and correct it? I've see late vblank events a bunch but this is... different :D -- You are receiving this mail because: You are watching all bug changes.
