diff options
author | danakj@chromium.org <danakj@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-04-10 04:44:49 +0000 |
---|---|---|
committer | danakj@chromium.org <danakj@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-04-10 04:44:49 +0000 |
commit | b7cfc63c8df1f29996806b1c9395c2a5471b2c99 (patch) | |
tree | 0298586956136e4c47d43cdbebbaef92b01663c3 /cc/test/test_web_graphics_context_3d.h | |
parent | d1ba019278fb7ff108a2ceb5312599f909ac5c6d (diff) | |
download | chromium_src-b7cfc63c8df1f29996806b1c9395c2a5471b2c99.zip chromium_src-b7cfc63c8df1f29996806b1c9395c2a5471b2c99.tar.gz chromium_src-b7cfc63c8df1f29996806b1c9395c2a5471b2c99.tar.bz2 |
cc: Move video upload to VideoResourceUpdater.
The VideoLayerImpl currently does upload of video frames from media::VideoFrame
to hardware/software resources, and displays these resources through quads. This
code is unfriendly to ubercomp as it requires holding onto the hardware resources
when using hardware decode, and because it reuses the same textures every frame
even though they need to be sent to the parent compositor.
This CL introduces the VideoResourceUpdater class, and moves all logic around
media::VideoFrame to that class. The VideoResourceUpdater class takes as input
a VideoFrame, and produces a set of TextureMailboxes for the video layer to
consume.
In the software case, the VideoResourceUpdater sets itself up as the release
callback so it can delete the backing texture when the browser compositor is
done with it (it could recycle it in the future).
In the hardware case, the VideoResourceUpdater takes a callback as input, so
it can have the WebMediaPlayer notified when the texture is given back from
the browser, and the hardware decoder can use it again for writing.
This CL also prepares us better for software uber-compositing video. The video
layer deals now only with abstract "resources", except for the mailboxes for
ubercompositor. The TextureMailbox construct needs to be abstracted in order to
hold a hardware or software backing for ubercompositor. Then the video layer's
special-case code for software can be entirely removed and it will be fully
software-uber-compositor-ready.
Currently, the VideoLayerImpl just makes use of the VideoResourceUpdater class,
making this a refactor without any functional change. This will make video
playback in ubercompositor work correctly for software-decoded video. In order
to address hardware-decoded video, a followup CL will have the WebMediaPlayer
hook up a callback through the VideoResourceUpdater to ensure it doesn't reuse
a texture for decode until it is returned from the parent compositor.
R=enne,jamesr
BUG=179729
Review URL: https://chromiumcodereview.appspot.com/13445009
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@193323 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'cc/test/test_web_graphics_context_3d.h')
-rw-r--r-- | cc/test/test_web_graphics_context_3d.h | 6 |
1 files changed, 6 insertions, 0 deletions
diff --git a/cc/test/test_web_graphics_context_3d.h b/cc/test/test_web_graphics_context_3d.h index 47f2054..82dd63e 100644 --- a/cc/test/test_web_graphics_context_3d.h +++ b/cc/test/test_web_graphics_context_3d.h @@ -89,6 +89,12 @@ class TestWebGraphicsContext3D : public FakeWebGraphicsContext3D { WebKit::WGC3Denum pname, WebKit::WGC3Duint* params); + virtual void genMailboxCHROMIUM(WebKit::WGC3Dbyte* mailbox); + virtual void produceTextureCHROMIUM(WebKit::WGC3Denum target, + const WebKit::WGC3Dbyte* mailbox) { } + virtual void consumeTextureCHROMIUM(WebKit::WGC3Denum target, + const WebKit::WGC3Dbyte* mailbox) { } + virtual void setContextLostCallback( WebGraphicsContextLostCallback* callback); |