[Chromoting] Fallback to use software renderer if desktop image size is larger than GPU limitaiton

remoting/host/desktop_session_agent.cc

Index: remoting/host/desktop_session_agent.cc
diff --git a/remoting/host/desktop_session_agent.cc b/remoting/host/desktop_session_agent.cc
index 200c33442fd6cad53b24ef91aa31eda8da45014a..8b1fc2ec970821515b4667628df1c7b69df44a9c 100644
--- a/remoting/host/desktop_session_agent.cc
+++ b/remoting/host/desktop_session_agent.cc
@@ -457,14 +457,17 @@ void DesktopSessionAgent::Stop() {
 void DesktopSessionAgent::OnCaptureFrame() {
   DCHECK(caller_task_runner_->BelongsToCurrentThread());
 
-  mouse_cursor_monitor_->Capture();
-
   // webrtc::DesktopCapturer supports a very few (currently 2) outstanding
   // capture requests. The requests are serialized on
   // |video_capture_task_runner()| task runner. If the client issues more
   // requests, pixel data in captured frames will likely be corrupted but
   // stability of webrtc::DesktopCapturer will not be affected.
   video_capturer_->Capture(webrtc::DesktopRegion());
+
+  // Note, the client may switch between hardware and software renderers
+  // according to the first desktop image. So we need to make sure the first
+  // desktop image has been sent before the mouse cursor.
+  mouse_cursor_monitor_->Capture();

[Sergey Ulanov, 2016/07/14 17:45:28]

This doesn't guarantee that the cursor will be received after the first frame.
Cursor shape and video are sent on different channels, independent of each
other, so capture ordering here will have very little effect on how the messages
are received on the client.

But I don't see how it's related to this change. VideoRenderer is not
responsible for the cursor.

[Hzj_jie, 2016/07/15 02:30:50]

Sorry, my fault. I have double confirmed, the mouse cursor should be able to
render. There must be some other issues before.

 }
 
 void DesktopSessionAgent::OnInjectClipboardEvent(