SkiaRenderer Usable on WebView Render Thread |
|||
Issue descriptionWhen running under WebView, we need to perform final drawing on the WebView render thread, on a different context than the GPU main thread. The simplest thing to do is likely to re-use existing mechanisms and both generate SkDDLs and draw these DDLs in sequence on the render thread. The more efficient thing to do (and one which may provide a good benefit to WebView) is to generate SkDDLs as normal on the Viz thread and then just play back the SkDDLs when needed on the compositor thread. We need to come up with a concrete plan here and implement.
,
Jan 8
there is no "viz thread" in webview (not yet anyway). Right now it has to all be done on the render thread in a single callback
,
Jan 9
I'll help with this too. After the vk interop work is done.
,
Jan 9
Re #3, that will be great. I am learning the Android WebView and try to understand what do we need for it.
,
Jan 9
Looks like Android WebView has two GPU services (A, B). A is running in a dedicated GPU thread. B is running in the Android render thread. A executes GL commands from Chrome renderer and browser UI. B executes GL commands from Display compositor. They share textures via EGLImage. For SkiaRenderer with OOP-R, All raster decoders and display compositor share one GLContext and one GrContext. But it will not work for Android WebView, since OOP-R decoder is on thread A, SkiaRenderer will be on thread B. They can not share GlContext and GrContext. We need have a plan for it.
,
Jan 9
Webview doesn't have browser UI, but other than that, all correct. > All raster decoders and display compositor share one GLContext and one GrContext. Yeah that's a problem for webview. Do they actually use the same GLContextVirtual (and whatever GrContext equivalent of virtual context is) as well, or different virtual context with the same underlying GLContextEGL? Webview will have texture sharing with SharedImage backed by AHB, so if we just need to make sure textures appears to be shared across two virtual contexts, then we can probably make that work.
,
Jan 9
Yes. They use the same GLContextVirtual. For WebView, I think we need at least two real GLContexts for those two GPU services.
,
Jan 9
So what other state needs to shared between raster display compositor, other than textures?
,
Jan 9
Re #8: Technically nothing needs other than the SharedImages need to be shared. But we're currently sharing extensively as a performance optimization for Skia (e.g. can use same Skia resource caches for OOP-R and display). We haven't measured the impact of this optimization.
,
Jan 15
|
|||
►
Sign in to add a comment |
|||
Comment 1 by ericrk@chromium.org
, Jan 8Cc: rjkroege@chromium.org ericrk@chromium.org
Owner: penghuang@chromium.org