Make Graphics3D::SwapBuffers take a completion callback

Make Graphics3D::SwapBuffers take a completion callback

BUG=none
TEST=with demo_simple_vertex_shader, rate control works

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=70474

[piman, 2010-12-16 02:14:58]

Alok: this is going towards the implementation of your bigger refactor, in
particular it pipes the logic for the completion callback.

[apatrick, 2010-12-16 03:36:37]

http://codereview.chromium.org/5944001/diff/1/chrome/renderer/webgraphicscont...
File chrome/renderer/webgraphicscontext3d_command_buffer_impl.cc (right):

http://codereview.chromium.org/5944001/diff/1/chrome/renderer/webgraphicscont...
chrome/renderer/webgraphicscontext3d_command_buffer_impl.cc:120:
ggl::SetSwapBuffersCallback(
Is there a danger that the callback will keep the RenderView alive until a
SwapBuffers notification comes in (if ever)? I was expecting the callback to be
set on the offscreen context associated with the plugin instance. I already
added one to schedule a composite when a plugin has rendered a frame. Also, what
if the plugin instance is offscreen? We are liable to not schedule a composite
if it is not visible.

[piman, 2010-12-16 04:27:34]

http://codereview.chromium.org/5944001/diff/1/chrome/renderer/webgraphicscont...
File chrome/renderer/webgraphicscontext3d_command_buffer_impl.cc (right):

http://codereview.chromium.org/5944001/diff/1/chrome/renderer/webgraphicscont...
chrome/renderer/webgraphicscontext3d_command_buffer_impl.cc:120:
ggl::SetSwapBuffersCallback(
On 2010/12/16 03:36:38, apatrick wrote:
> Is there a danger that the callback will keep the RenderView alive until a
> SwapBuffers notification comes in (if ever)?

NewCallback doesn't refcount the RenderView, so I don't think there's an issue
there.

> I was expecting the callback to be
> set on the offscreen context associated with the plugin instance. I already
> added one to schedule a composite when a plugin has rendered a frame. Also,
what
> if the plugin instance is offscreen? We are liable to not schedule a composite
> if it is not visible.

Not scheduling a composite is exactly what we want. The callback is meant for
end-to-end rate control, so that the plugin doesn't keep rendering frames that
will never be displayed. This is the same behavior when accelerated compositing
is off.

So plugin's SwapBuffers() [3D] or Flush() [2D] schedules a redraw [compositing
off] or composite [compositing on]. When that one is sent to the GPU process
[compositing on] or browser process [compositing off], DidInitiatePaint needs to
be called. When it is finished, DidFlushPaint needs to be called. This callback
corresponds to RenderWidget::OnUpdateRectAck.

Note that technically this is needed for the 2D case to work correctly in case
of the accelerated compositing (e.g. a 2D pepper plugin with an animated css
transform on it).

[apatrick, 2010-12-16 18:43:54]

Thanks for the explanation. LGTM.

[piman, 2010-12-17 05:05:29]

PTAL. I missed the demo framework initially.

[apatrick, 2011-01-04 18:12:46]

Sorry for the delay. LGTM.

[piman, 2011-01-04 22:27:48]

On Tue, Jan 4, 2011 at 10:12 AM, <apatrick@google.com> wrote:

> Sorry for the delay. LGTM.
>
> http://codereview.chromium.org/5944001/
>

Actually I will have to rework this with all of Alok's changes.

Antoine

[piman, 2011-01-05 00:49:56]

PTAL, hopefully for the last time. I tested with the samples and it works, but
I'm still working on updating the Flash code to test with it.

[apatrick, 2011-01-05 01:08:29]

LGTM