[Webkit-unassigned] [Bug 216106] [iOS WK1] Crashes when using ANGLE WebGL from another thread

[bugzilla-daemon at webkit.org]

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

Kenneth Russell <kbr at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kbr at google.com

--- Comment #1 from Kenneth Russell <kbr at google.com> ---
As discussed with Dean, some of these cases were already subtly broken prior to the switch to ANGLE, because WebGLRenderingContextBase makes its EAGL context current on the first thread it's used on. However, there are new failure modes with ANGLE because of its internal context virtualization.

Two changes - one in ANGLE, one in WebKit - are necessary to fix this:

1) ANGLE must offer a way to disable its context virtualization, and that must be used in UIWebView (ideally, only there, since virtualization offers performance benefits). Tracked in https://bugs.chromium.org/p/angleproject/issues/detail?id=5010 and dependent bug.

2) WebKit must release the GraphicsContextGL when a thread's done with its WebGL work. A new "releaseContext()" must be added along "makeContextCurrent()" in GraphicsContextGLOpenGL.

To avoid releasing the context too often, it would be ideal to do it less often than after each WebGL API call.

dino@ mentioned that when touch events are dispatched (on a different thread than the web main thread), a lock is grabbed that prevents concurrent access to the DOM. Could anyone offer a pointer to that code?

If we could store the current GraphicsContextGLOpenGL somewhere, and release it when the touch event handler exits (just before releasing that lock), that would handle that thread's case.

For the main thread, it would also be ideal to release any current GraphicsContextGLOpenGL when that DOM lock is released. I'm not sure how often that lock is acquired and released - any pointers to the code which manages it on the main thread?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200902/aef33037/attachment.htm>