RESOLVED FIXED 217218
Refactor VideoTextureCopier to be specific to a particular GraphicsContextGL and polymorphic to it
https://bugs.webkit.org/show_bug.cgi?id=217218
Summary Refactor VideoTextureCopier to be specific to a particular GraphicsContextGL ...
Kimmo Kinnunen
Reported 2020-10-02 04:40:59 PDT
Refactor VideoTextureCopier to be specific to a particular GraphicsContextGL and polymorphic to it VideoTextureCopierCV VideoTextureCopierGStreamer Solves two problems: 1) No reason to create copier per media object -> If context is lost, media object caches stale converter?' -> Creates conversion shaders per media object, not per graphics context 2) Not possible to create remote version of this -> Need to refactor before being able to not use GraphicsContextGLOpenGL Should be: GraphicsContectGL::copyImageToPlatformTexture GraphicsContextGL::copyVideoTextureToPlatformTexture OR GraphicsContectGL::getVideoTextureCopier
Attachments
Patch (127.09 KB, patch)
2020-10-28 05:30 PDT, Kimmo Kinnunen
no flags
Patch (127.03 KB, patch)
2020-11-10 23:44 PST, Kimmo Kinnunen
no flags
Radar WebKit Bug Importer
Comment 1 2020-10-02 04:41:24 PDT
Kimmo Kinnunen
Comment 2 2020-10-26 06:26:20 PDT
This is needed for web process video drawing to web process webgl canvas after WebGL is using GraphicsContextGL interface. This is needed for web process video drawing to remote webgl canvas (transitional feature).
Kimmo Kinnunen
Comment 3 2020-10-28 05:30:01 PDT
Kimmo Kinnunen
Comment 4 2020-11-10 23:44:54 PST
Dean Jackson
Comment 5 2020-11-11 01:09:41 PST
Comment on attachment 413789 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=413789&action=review > Source/WebCore/platform/graphics/GraphicsContextGL.h:1300 > + virtual GraphicsContextGLCV* asCV() = 0; I wonder if we should just expose copyPixelBufferToTexture on GraphicsContextGL directly, and have the context keep the GraphicsContextGLCV class for internal use?
Kimmo Kinnunen
Comment 6 2020-11-11 01:25:02 PST
Comment on attachment 413789 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=413789&action=review >> Source/WebCore/platform/graphics/GraphicsContextGL.h:1300 >> + virtual GraphicsContextGLCV* asCV() = 0; > > I wonder if we should just expose copyPixelBufferToTexture on GraphicsContextGL directly, and have the context keep the GraphicsContextGLCV class for internal use? So the idea here is that there could be GraphicsContextGLGStreamer interface for GStreamer specific things, like GStreamer specific copyGStreamerImageToTexture(somespecificaparameters). Also if some day there is other platforms with other APIs, those could have their own interface. This way we solve: - avoid having union of all needed parameters in the method calls. E.g. GStreamer has "image orientation" to be passed, where as Cocoa does not have that. - avoid having empty functions for platforms not needing a certain function - avoid having PlatformNativePixelBuffer typedef abstractions that may conflict (e.g. some platforms might have two such abstractions, other platform might have only one).
Kimmo Kinnunen
Comment 7 2020-11-11 01:28:06 PST
So wrt what we talked off-line about ExtensionsGL, GraphicsContextGLCV is the concept of ExtensionsGL done in a way (that I think) probably originally was sort-of envisioned.
Kimmo Kinnunen
Comment 8 2020-11-11 01:32:26 PST
And to elaborate: In case we want a generic function call, and eventually we probably should want it, we should add copyImageBufferToTexture() call, and extend the WebCore::ImageBuffer abstraction so that native video objects can be wrapped into the ImageBuffer. Similar to eventually we should make GraphicsContextGL to draw to WebCore::ImageBuffer, so that then we can draw WebGL context to WebGL context in generic way by drawing ImageBuffer to the WebGL context
EWS
Comment 9 2020-11-11 02:44:48 PST
Committed r269678: <https://trac.webkit.org/changeset/269678> All reviewed patches have been landed. Closing bug and clearing flags on attachment 413789 [details].
Dean Jackson
Comment 10 2020-11-11 12:08:48 PST
Sounds good!
Note You need to log in before you can comment on or make changes to this bug.