Enabling touchspots or software cursor makes compositing stutter and jerky

What fingerpaint looks like now (since r1924).

What fingerpaint looked like before (or without touchspots, pending the fix for bug 1372850 landing).

This should be actually "High, but "Medium" is ok since it hasn't been released.

I just spent about 30 minutes going back and forth between fingerpaint under demo_shell with and without touchspots and couldn't convince myself there was any substantial difference. Still investigating though...

It's hard to tell. I tried to eliminate the human variance in touch smoothness, which I found to be quite high despite my best attempts to keep a steady hand:

umockdev-record /dev/input/event4 > mtk-tpd.evdev
umockdev-record -i /dev/input/event4=mtk-tpd.ioctl -e /dev/input/event4=mtk-tpd.evemu -- mir_demo_server_shell &
mir_demo_client_fingerpaint

< Paint with fingers! >

Then I used

umockdev-run -d mtk-tpd.umockdev -e /dev/input/event4=mtk-tpd.evemu -i /dev/input/event4=mtk-tpd.ioctl -- mir_demo_server_shell & sleep 1 && mir_demo_client_fingerpaint

with and without touchspots enabled in order to produce screenshots

2:25 < racarr> http://imgur.com/umcK3VP
22:25 < racarr> without touchspots
22:25 < racarr> http://imgur.com/zYCwUTq
22:25 < racarr> with touchspots
22:25 < racarr> both have some irregulaties in the same spots
22:26 < racarr> due to finger jerkiness
22:26 < racarr> beyond that
22:26 < racarr> both have some random stuff
22:26 < racarr> e.g. without touchspots is jerkier
22:26 < racarr> ont he big blue vertical line
22:26 < racarr> with touchspots is jerkier in the horizontal area towards the top

I don't think there is a substantial difference.

You seem to have forgotten two crucial parameters required to reproduce the bug :) Enable touchspots on the server, and force vsync on (-w) in fingerpaint:

  1. mir_demo_server_minimal --enable-touchspots &
  2. mir_demo_client_fingerpaint -w
  3. Draw!

If you still can't reproduce it then I suggest taking some new recordings because the difference is still visibly dramatic for me (Nexus 4).

As mentioned in the original bug, I think this is triggering a pre-existing problem with our compositor logic. It should be able to deal with a high rate of scene change events without affecting compositing performance.

If that assessment is correct then it's probably the MultithreadedCompositor code that needs improving and not touchspots.

I did use enable touchspots on the server side :) how the two images were produced...did not use -w for fingerpaint will try again tomorrow.

New traces with -w

without spots: http://imgur.com/T0QJeXl

with spots: http://imgur.com/OZmOsWY

Weird. It looks like your automation methodology is missing something (?!) because the difference is visibly dramatic for me when using a real finger.

Screenshot of jerky input events using touchspots with the latest development branch r1941.

Screenshot of smoother input events (no touchspots) with the latest development branch r1941.

Can't reproduce this right now. It might have been fixed as a result of other work.

Aha! It seems to be the delays introduced in excessive compositor switching (bug 1373696) that's causing the gaps in my smooth lines here. Fix bug 1373696 and this one should be resolved. Or just use the workaround (disable Android overlays).

Reproduced on krillin.

Now we have software cursor, this bug is permanently on for touch devices.

This is a dup of https://bugs.launchpad.net/mir/+bug/1339749 (or that's a dup of this one)

Also, I think the software cursor is disabled on the images, so not quite yet in the wild... It also only should become a factor in high-movement, low-buffer-update scenarios (like touchspots)

I don't think bug 1339749 is as usefully descriptive as this one. Either make this one the primary bug or keep both open I say.

I've generalized bug 1373696 so this is now a duplicate of that.