[Webkit-unassigned] [Bug 76720] [chromium] Refactor video drawing to be more data driven

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=76720





--- Comment #19 from Adrienne Walker <enne at google.com>  2012-01-30 14:30:03 PST ---
(In reply to comment #18)
> (In reply to comment #17)
> > No, these are all draw-only state and they should live on the one quad that the video layer produces.
> 
> I was under the impression that each frame, the CCVideoLayerImpl produces a brand new quad, but the ManagedTexture objects are used in multiple frames.
> 
> Currently, the ManagedTexture objects are allocated in CCVideoLayerImpl::reserveTextures. A new ManagedTexture is only created if the layer doesn't have a texture for a specific plane. If my understanding is correct, that means that ManagedTexture objects will be reused for multiple frames. If we switch to calling reserveTextures in the quad, without a backpointer to the layer, then we'll only be able to use each ManagedTexture for one frame.
> 
> Does that sound correct?

Yeah, you have the right picture.  We shouldn't need to get a new ManagedTexture each frame.

I think you could just call reserveTextures as a part of the willDraw() function, and pass the texture ids and frame to the quad, where it can do the upload as needed without needing to touch the layer anymore.

Or, in other words, separate out copyFrameToTexture's responsibilities into two pieces: the layer mutation piece (which lives on the layer) and the upload piece (which could live in LRC as a part of quad drawing).

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.