This is a monster CL.

It started as an attempt to put the decoder onto another thread.  However, this became complicated due to multiple object ownership transfers and coupling between the decode layer and the network layer; the decoder's states were highly coupled with how the network packets were processed.

This could probably be broken up slightly, but at this point, it's easier to just commit as a whole  The refactor includes:
  1) Making the decoder interface unaware of "network packet" types.
  2) Making the network layer process packets in order.
  3) Threading through asynchronous APIs all over the place.
  4) Simplifying the rectangle update protocol.
  5) Cleaning up object lifetime and ownership semantics between the decode layer and the renderer.

As of right now, the Verbatim format is still broken on the encode side because it uses the old protocol.

BUG=52883, 57351
TEST=still connects to chromoting_simple_host

Review URL: http://codereview.chromium.org/3305001

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@61402 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 2 insertions, 0 deletions

diff --git a/remoting/client/plugin/chromoting_instance.h b/remoting/client/plugin/chromoting_instance.h
index ee9b1df..6c9d7c0 100644
--- a/remoting/client/plugin/chromoting_instance.h
+++ b/remoting/client/plugin/chromoting_instance.h
@@ -39,6 +39,7 @@ class HostConnection;
 class InputHandler;
 class JingleThread;
 class PepperView;
+class RectangleUpdateDecoder;
 
 class ChromotingInstance : public pp::Instance {
  public:
@@ -70,6 +71,7 @@ class ChromotingInstance : public pp::Instance {
   ClientContext context_;
   scoped_ptr<HostConnection> host_connection_;
   scoped_ptr<PepperView> view_;
+  scoped_ptr<RectangleUpdateDecoder> rectangle_decoder_;
   scoped_ptr<InputHandler> input_handler_;
   scoped_ptr<ChromotingClient> client_;
   pp::Var instance_object_;  // JavaScript interface to control this instance.