Issue the correct Pepper flow control calls in threaded mode

Issue the correct Pepper flow control calls in threaded mode

BUG=119821
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=128872

[piman, 2012-03-26 04:00:47]

lgtm

[Wez, 2012-03-26 04:03:28]

On Mar 25, 2012 10:25 PM, <nduca@chromium.org> wrote:
>
> Reviewers: piman, Wez,
>
> Description:
> Issue the correct Pepper flow control calls in threaded mode
>
> BUG=119821
>
>
> Please review this at http://codereview.chromium.org/9856005/
>
> SVN Base: svn://svn.chromium.org/chrome/trunk/src
>
> Affected files:
>  M content/renderer/render_widget.h
>  M content/renderer/render_widget.cc
>
>
> Index: content/renderer/render_widget.cc
> diff --git a/content/renderer/render_widget.cc
b/content/renderer/render_widget.cc
> index
33d2bd5c7aae9b87f925080e9f1ae238d0384ee2..610aa90bd07c21fafe751f3e4640c5f178158ab5
100644
> --- a/content/renderer/render_widget.cc
> +++ b/content/renderer/render_widget.cc
> @@ -1108,6 +1108,11 @@ void RenderWidget::didDeactivateCompositor() {
>     using_asynchronous_swapbuffers_ = false;
>  }
>
> +void RenderWidget::willBeginFrame() {
> +  TRACE_EVENT0("gpu", "RenderWidget::willBeginFrame");
> +  WillInitiatePaint();
> +}
> +
>  void RenderWidget::didCommitAndDrawCompositorFrame() {
>   TRACE_EVENT0("gpu", "RenderWidget::didCommitAndDrawCompositorFrame");
>   // Accelerated FPS tick for performance tests. See throughput_tests.cc.
> @@ -1118,6 +1123,11 @@ void
RenderWidget::didCommitAndDrawCompositorFrame() {
>  }
>
>  void RenderWidget::didCompleteSwapBuffers() {
> +  CompositorThread* compositor_thread =
> +      RenderThreadImpl::current()->compositor_thread();
> +  if (compositor_thread)
> +    DidFlushPaint();

Under what circumstances do we get didCompleteSwapBuffers without a
compositor thread?

> +
>   if (update_reply_pending_)
>     return;
>
> Index: content/renderer/render_widget.h
> diff --git a/content/renderer/render_widget.h
b/content/renderer/render_widget.h
> index
3f17d53c09f390ef003b75aa93f89dfae7bbd497..b73e6ab049c538a77c3325e5f58b20cc55ec930d
100644
> --- a/content/renderer/render_widget.h
> +++ b/content/renderer/render_widget.h
> @@ -113,6 +113,7 @@ class CONTENT_EXPORT RenderWidget
>   virtual bool Send(IPC::Message* msg) OVERRIDE;
>
>   // WebKit::WebWidgetClient
> +  virtual void willBeginFrame();
>   virtual void didInvalidateRect(const WebKit::WebRect&);
>   virtual void didScrollRect(int dx, int dy, const WebKit::WebRect&
clipRect);
>   virtual void didAutoResize(const WebKit::WebSize& new_size);
>
>

[nduca, 2012-03-26 05:16:12]

On 2012/03/26 04:03:28, Wez wrote:
> Under what circumstances do we get didCompleteSwapBuffers without a
> compositor thread?

Not neeed. :) Removing

[Wez, 2012-03-26 12:33:35]

Lgtm
On Mar 26, 2012 1:16 AM, <nduca@chromium.org> wrote:

> On 2012/03/26 04:03:28, Wez wrote:
>
>> Under what circumstances do we get didCompleteSwapBuffers without a
>> compositor thread?
>>
>
> Not neeed. :) Removing
>
>
http://codereview.chromium.**org/9856005/<http://codereview.chromium.org/9856...
>

[Wez, 2012-03-26 12:33:39]

Lgtm
On Mar 26, 2012 1:16 AM, <nduca@chromium.org> wrote:

> On 2012/03/26 04:03:28, Wez wrote:
>
>> Under what circumstances do we get didCompleteSwapBuffers without a
>> compositor thread?
>>
>
> Not neeed. :) Removing
>
>
http://codereview.chromium.**org/9856005/<http://codereview.chromium.org/9856...
>

[jar (doing other things), 2012-03-28 19:13:26]

Drive by question: When/where does willBeginCompositorFrame() get called? 

Thanks.

[nduca, 2012-03-28 19:19:01]

On 2012/03/28 19:13:26, jar wrote:
Its a method on the WebWidget interface. It comes up from the bowels of the
compositor.

[nduca, 2012-03-28 19:19:14]

Erm, WebWidgetClient. But still, bowels.