Over to rjkroege@ for placement in bug hierarchy. Please assign to me once done (I'll either take this or triage). Thanks!

Was looking around on code search. Question:

What do you mean exactly by thread safe in this case? SharedImageInterfaceProxy is thread safe, but that's on the client side. For webview's case, I think we need to make SharedImageManager (and MailboxManagerImpl?) thread safe, then share the same instance across GPU thread and android render thread.

Or am I totally misreading this?

Yes, we need to make SharedImageManager thread-safe for this use case, and create backings that are thread-safe as well for images that are shared with WebView. SharedImageRepresentations can be single-thread. Begin/End is when we can update any needed state between the representations and the backing (under lock).

More questions :p

I assume we need new backing for EGL image, like MailboxManagerSync today?

I saw a backing for AHardwareBuffer. I assume that's for using surfaceflinger to composite in chrome? Maybe webview can use it just for texture sharing across threads. Webview makes a copy of video textures to get around EGL image's limitation that only one EGL image created from a buffer source. I think AHardwareBuffer doesn't have that limitation, so maybe we can use AHardwareBuffer and then remove that extra copy, on android versions that support AHardwareBuffer at least..

> I assume we need new backing for EGL image, like MailboxManagerSync today?

Yes. We can reuse the AHB one for O+, but for before that we probably need a texture+EGLImage one.

> I saw a backing for AHardwareBuffer. I assume that's for using surfaceflinger to composite in chrome? Maybe webview can use it just for texture sharing across threads. Webview makes a copy of video textures to get around EGL image's limitation that only one EGL image created from a buffer source. I think AHardwareBuffer doesn't have that limitation, so maybe we can use AHardwareBuffer and then remove that extra copy, on android versions that support AHardwareBuffer at least..

Correct that AHB shouldn't have that limitation. That said, the copy shouldn't be needed at a fundamental level, but is a limitation of how MailboxManagerSync works. With shared image backings, I think we should be able to use the EGLImage created for video (even if it's not AHB-backed) and bind it to different textures on different threads, skipping the copy.