[Webkit-unassigned] [Bug 43590] Implementing video frame sharing between WebKit and Chromium

[bugzilla-daemon at webkit.org]

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





--- Comment #10 from Darin Fisher (:fishd, Google) <fishd at chromium.org>  2010-08-13 21:29:02 PST ---
(From update of attachment 63661)
WebKit/chromium/src/VideoFrameChromiumImpl.cpp:13
 +  WebVideoFrame* VideoFrameChromiumImpl::toWebVideoFrame(WebCore::VideoFrameChromium* frame)
the choice of variable names "frame" and "m_webFrame" is probably
not so great since those are used when we have WebCore::Frame
and WebKit::WebFrame pointers.

WebKit/chromium/public/WebVideoFrame.h:41
 +      // WebKit::WebVideoFrame.
it is fairly unfortunate that we need to replicate all of these constants.

WebCore/platform/graphics/chromium/VideoFrameChromium.h:74
 +      virtual SurfaceType type() const = 0;
i don't see any usage of type and format methods.  is that an oversight?
or just something that will happen later?

WebKit/chromium/public/WebVideoFrame.h:75
 +      virtual SurfaceType type() const = 0;
instead of exposing all of this information, have you considered
just having a method on this interface that you can call to load
the frame into a GLES2 texture?  how much information about the
frame do you really need to expose to WebKit?

WebCore/platform/graphics/chromium/VideoFrameChromium.h:36
 +  class VideoFrameChromium {
we typically avoid this double thunking by making the WebCore "interface"
use non virtual methods.  then, we just provide the concrete implementation
in WebKit/chromium/src/, and that implementation then calls out to the
WebKit API equivalent which provides the virtual functions.

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