Merge lp:~thomas-voss/mir/test_an_idea into lp:mir/0.18

[Thomas Voß]

Completely disable batching and resampling.

Completely disable batching and resampling.

[Daniel van Vugt (vanvugt)]

Jenkins isn't running on the target branch lp:mir/0.17...

Also I don't recommend disabling batching and resampling. Latency will become much higher as the raw event rate is higher than the frame rate, so the screen gets indefinitely further and further behind the input during a gesture.

Although on that note I noticed mako devel-proposed recently dropped its raw event rate from 96Hz to around 60Hz to match the screen (mako kernel change??). That's still not best practice though -- we get lower latency using our 59Hz default, so as to avoid filling the long buffer queues we have (two triple-buffer queues would give 4 frames latency otherwise, this way it's only around 2 frames latency).

[Daniel van Vugt (vanvugt)]

Sorry, silly me, you're not completely disabling it. Here's a proper review having manually tested it now...

(1) Needs information: We need to analyse 3rd_party/android-input/android/frameworks/base/services/input/InputTransport.cpp in greater detail to assess if this change is safe or desirable. My original interpretation was that passing false for event_rate_hz clients (like our fingerpaint and target demos) might defer delivery of events to the client indefinitely, which is bad. Was that interpretation wrong? Maybe.

(2) Resubmit: Any real change needs to target lp:mir first.

review: Needs Resubmitting

[Daniel van Vugt (vanvugt)]

*"for event_rate_hz=0 clients"

[Daniel van Vugt (vanvugt)]

That all said, the change proposed here only applies to clients who set their input rate to zero (clients that are advanced enough to handle very high even rates without lag). I'm not sure and doubt that should include Unity8 or USC just yet.

If a client is not advanced enough to handle it and you do set MIR_CLIENT_INPUT_RATE=0 then that client will experience very high input lag.

[Daniel van Vugt (vanvugt)]

Correction:

That all said, the change proposed here only applies to clients who set their input rate to zero (clients that are advanced enough to handle very high event rates without lag). I'm not sure and doubt that should include Unity8 or Qt clients just yet.

If a client is not advanced enough to handle it and you do set MIR_CLIENT_INPUT_RATE=0 then that client will experience very high input lag. Much higher than we see on the phone today.

[Kevin DuBois (kdub)]

mir 0.18 is coming around soon, might need to retarget for testing purposes

[Daniel van Vugt (vanvugt)]

Ha. Sorry Mir 0.18.0 is now released. Need to re-target lp:mir

review: Needs Resubmitting

Unmerged revisions

3023. By Thomas Voß on 2015-12-11

Completely disable batching and resampling

=== modified file 'src/client/input/android/android_input_receiver.cpp'
--- src/client/input/android/android_input_receiver.cpp	2015-10-26 03:33:22 +0000
+++ src/client/input/android/android_input_receiver.cpp	2015-12-23 14:09:12 +0000
@@ -171,7 +171,7 @@
     }
 
     auto result = input_consumer->consume(&event_factory,
-                                          true,
+                                          event_rate_hz > 0,
                                           frame_time,
                                           &event_sequence_id,
                                           &android_event);