diff options
author | jiesun@google.com <jiesun@google.com@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-07-14 21:00:25 +0000 |
---|---|---|
committer | jiesun@google.com <jiesun@google.com@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-07-14 21:00:25 +0000 |
commit | d3d048776df1ba9ad87a884a2cd5a0a944b52cda (patch) | |
tree | a95dbf055838997db5b5b88d0a04a51f1fcc4beb /webkit/glue/media | |
parent | e7d9e170144853b9ef889ab5e5fcf44b4c9ef39d (diff) | |
download | chromium_src-d3d048776df1ba9ad87a884a2cd5a0a944b52cda.zip chromium_src-d3d048776df1ba9ad87a884a2cd5a0a944b52cda.tar.gz chromium_src-d3d048776df1ba9ad87a884a2cd5a0a944b52cda.tar.bz2 |
media: refactoring video_render_base to recycle buffers
To make recycle work, we had to define the usage scope of current frame. otherwise we are introducing tearing because we will begin to decode into the buffer before it is done by the renderer/painter/compositor.
current mechanism depends on hold reference of a copied picture. we had no that luxury if we do not copy output buffers. we had to compromise by
1. in pause() ( which is not the sense of pipeline->pause(), which is implemented by set playrate = 0 ) in filter->pause() ( or in the future flush() ), which is part of seeking ( and in the future, part of stop() too) , we had to return all the buffers to owner. we had no current buffer to display. we use NULL as current frame in this case.
2. remove black frame from render base, this is only valid for system memory based video frame, even that should we use color fill instead of color conversion and scale.
3. pause and stop has to wait for pending read (actually flush) and pending paint.
4. we only advance frame when there are two or more frames in ready queue.
Review URL: http://codereview.chromium.org/2836038
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@52398 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'webkit/glue/media')
-rw-r--r-- | webkit/glue/media/video_renderer_impl.cc | 18 |
1 files changed, 14 insertions, 4 deletions
diff --git a/webkit/glue/media/video_renderer_impl.cc b/webkit/glue/media/video_renderer_impl.cc index 1ba51f2..796d07f 100644 --- a/webkit/glue/media/video_renderer_impl.cc +++ b/webkit/glue/media/video_renderer_impl.cc @@ -66,7 +66,16 @@ void VideoRendererImpl::Paint(skia::PlatformCanvas* canvas, const gfx::Rect& dest_rect) { scoped_refptr<media::VideoFrame> video_frame; GetCurrentFrame(&video_frame); - if (video_frame) { + if (!video_frame) { + SkPaint paint; + paint.setColor(SK_ColorBLACK); + canvas->drawRectCoords( + static_cast<float>(dest_rect.x()), + static_cast<float>(dest_rect.y()), + static_cast<float>(dest_rect.right()), + static_cast<float>(dest_rect.bottom()), + paint); + } else { if (CanFastPaint(canvas, dest_rect)) { FastPaint(video_frame, canvas, dest_rect); } else { @@ -81,8 +90,9 @@ void VideoRendererImpl::Paint(skia::PlatformCanvas* canvas, LOG(INFO) << "pts=" << video_frame->GetTimestamp().InMicroseconds(); } - video_frame = NULL; } + + PutCurrentFrame(video_frame); } // CanFastPaint is a helper method to determine the conditions for fast @@ -99,14 +109,14 @@ bool VideoRendererImpl::CanFastPaint(skia::PlatformCanvas* canvas, // paint if opacity is not 1.0. Since alpha = opacity * 0xFF, we check that // alpha != 0xFF. // - // Additonal notes: If opacity = 0.0, the chrome dispaly engine does not try + // Additonal notes: If opacity = 0.0, the chrome display engine does not try // to render the video. So, this method is never called. However, if the // opacity = 0.0001, alpha is again 0, but the display engine tries to render // the video. If we use Fast paint, the video shows up with opacity = 1.0. // Hence we use slow paint also in the case where alpha = 0. It would be ideal // if rendering was never called even for cases where alpha is 0. Created // bug 48090 for this. - SkCanvas::LayerIter layer_iter(canvas, true); + SkCanvas::LayerIter layer_iter(canvas, false); SkColor sk_color = layer_iter.paint().getColor(); SkAlpha sk_alpha = SkColorGetA(sk_color); if (sk_alpha != 0xFF) { |