[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

--- Comment #3 from Dean Jackson <dino at apple.com> ---
(In reply to Kenneth Russell from comment #1)
> 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.

According to the Apple documentation, this isn't true.

https://developer.apple.com/library/archive/documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/ConcurrencyandOpenGLES/ConcurrencyandOpenGLES.html#//apple_ref/doc/uid/TP40008793-CH409-SW4

It's ok for the EAGLContext to be the current context in multiple threads. It's just not ok to use it from multiple threads at the same time, and we already guard against that by taking a Web Thread lock when we process events on the main thread.

However, we might have to call glFlush in this situation.

> 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?

This happens inside UIKit, not WebKit, unfortunately.

The code that calls _webTouchEventsRecognized has taken the WebThreadLock.

-- 
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/228f98c4/attachment.htm>