Introduce a client minimum picture pool size

remoting/client/plugin/pepper_video_renderer_3d.cc

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "remoting/client/plugin/pepper_video_renderer_3d.h"
 
 #include <math.h>
 
 #include "base/callback_helpers.h"
 #include "base/stl_util.h"
@@ skipping 153 matching lines @@
     case protocol::ChannelConfig::CODEC_VP8:
       video_profile = PP_VIDEOPROFILE_VP8_ANY;
       break;
     case protocol::ChannelConfig::CODEC_VP9:
       video_profile = PP_VIDEOPROFILE_VP9_ANY;
       break;
     default:
       NOTREACHED();
   }
   int32_t result = video_decoder_.Initialize(
-      graphics_, video_profile, PP_HARDWAREACCELERATION_WITHFALLBACK,
+      graphics_, video_profile, PP_HARDWAREACCELERATION_WITHFALLBACK, 0,

[Sergey Ulanov, 2015/08/11 18:17:01]

What happens when a plugin calls GetPicture() while already holding certain
number previous frame? Can GetPicture() fail in that case because there are too
many frames allocated or will it delay completion until the previous frames are
returned?
Does it matter if the frames the plugin is holding are not sequential? I.e. if
there are 3 frames allocated total and the plugin holds frames N and N+2 can it
call GetPicture() to retrieve frame N+3 or does it have to return frame N first?

In either case, this class may call GetPicture() while holding previous 2
frames, so 0 is not correct here. It should be 3, if I understand the meaning
correctly.

[lpique, 2015/08/11 19:56:10]

At present, the call to GetPictures() succeeds (PP_OK_COMPLETIONPENDING), but
the callback is not invoked until there are pictures available, which may or may
not happen.

I'm not sure returning an error immediately (or through the callback either) is
useful. The ARC (plugin) code can't force a release of pictures back to the
PPAPI, and all it would do is to retry the GetPictures() call again, and
busy-wait.

To correct that, I would add code that would force the same sort of wait in the
ARC driver, so that it only calls GetPicture() if it knows pictures are
available. But all that is doing is moving the wait.
The ARC code is written to handle decoded frames being returned in arbitrary
order.
Ok, I will happily add a local constant declaring this part of the code requires
three.

I only used zero because it introduced the least amount of change. The
implementation takes this requested minimum and effectively does
"max(requested_by_client, required_by_decoder)", so the amount required by the
decoder would still be the count allocated. For the platforms I was testing ARC
on, I observed a picture pool size of five.

Done.

       callback_factory_.NewCallback(&PepperVideoRenderer3D::OnInitialized));
   CHECK_EQ(result, PP_OK_COMPLETIONPENDING)
       << "video_decoder_.Initialize() returned " << result;
 }
 
 ChromotingStats* PepperVideoRenderer3D::GetStats() {
   return &stats_;
 }
 
 protocol::VideoStub* PepperVideoRenderer3D::GetVideoStub() {
@@ skipping 345 matching lines @@
   gles2_if_->AttachShader(graphics_.pp_resource(), shader_program_, shader);
   gles2_if_->DeleteShader(graphics_.pp_resource(), shader);
 }
 
 void PepperVideoRenderer3D::CheckGLError() {
   GLenum error = gles2_if_->GetError(graphics_.pp_resource());
   CHECK_EQ(error, static_cast<GLenum>(GL_NO_ERROR)) << "GL error: " << error;
 }
 
 }  // namespace remoting