Client buffers eventually display one frame behind client swap requests
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mir |
Expired
|
Medium
|
Unassigned |
Bug Description
I've not been able to figure out exactly what causes this problem yet - but it appears that there is some sort of condition that can cause client buffers to display one-frame behind their swap count, eg:
swapN -> swapN + 1 -> swapN + 2
drawN - 1 -> drawN -> drawN + 1
I haven't been able to figure out a programmatic way to reproduce it, but gtk+ seems to be a good testcase so far:
http://
./autogen.sh --enable-
gdb ./demos/
Click on the "Page 2" tab and click on various widgets until there is visible input lag. Once there is input lag, you can break in mir_surface_
Changed in mir: | |
importance: | Undecided → High |
Sam, the existing manual test case for this sort of thing is to run demo_client_ fingerpaint and:
1. Drag/draw for a while.
2. Click single clicks in various locations.
Expect: Each single click (which is a single swap) results in a new colour being painted in that spot. Hence, no lag.
How does that go for you?
Of course, I thought the automated tests covered this too...