[Remoting Android] Move mRenderData into TouchInputHandler

remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java

Index: remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java
diff --git a/remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java b/remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java
index dcdbba1c5d5c76abaeec015aa0f8b45bb060f85e..2a057ff34421961bddacacbe1d77299ddb8a1ade 100644
--- a/remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java
+++ b/remoting/android/java/src/org/chromium/chromoting/DesktopCanvas.java
@@ -208,7 +208,7 @@ public class DesktopCanvas {
 
         mRenderData.transform.postTranslate(xAdjust, yAdjust);
 
-        mViewer.transformationChanged();
+        mViewer.transformationChanged(mRenderData.transform);

[Hzj_jie, 2016/08/25 21:55:14]

The safety of this logic depends on mRenderData will be accessed only in UI
thread. Would you mind to add a ThreadChecker to ensure this behavior?
An example is @
https://cs.chromium.org/chromium/src/third_party/webrtc/base/java/src/org/web....

But another suggestion to resolve this issue in a better pattern is to add
thread checking logic in the Event. i.e. A parameter to control whether an Event
can only be raised in a certain thread. Then it would be safe to assume all the
listeners will be executed in one thread. (transformationChangedEvent.Raise(new
Parameter(mRenderData.transform) instead of
mViewer.transformationChanged(mRenderData.transform)).

Same issue impacts cursor position and visibility.

[Yuwei, 2016/08/25 22:44:16]

But this is for WebRTC... Maybe have a simplified copy in our code base?
I think now it is basically a precondition that all public functions in Java can
only be used on the UI thread and RenderData is explicitly defined to be single
threaded so I'm less worried about the thread safety of mRenderData (or any
other classes that are not explicitly defined to be multi-threaded). We can have
a CL later to ensure thread safety if we think that's really useful.

[joedow, 2016/08/25 22:57:47]

We no longer need any synchronization on the Java side since all of the render
operations occur on the same thread.  On the native side, the updates are posted
to another thread.  I don't think we need any thread checking mechanism now
(though that would change if we added another thread in the future).

[Yuwei, 2016/08/25 23:14:35]

Looks like we do create anonymous thread for fetching OAuth token or refreshing
host list, but they don't expose the thread publicly and data will always be
consumed back in the UI thread.

A thread checker may be useful in that case to ensure thread safety. We can add
the thread checker later if we check in code like these.

[Hzj_jie, 2016/08/26 18:34:58]

Sorry, I have not followed up with Java code for a while, and I have not
realized this important change.

     }
 
     /**