Last Comment Bug 764578 - WebGL context creation keeps failing after D3D device has been lost
: WebGL context creation keeps failing after D3D device has been lost
Product: Core
Classification: Components
Component: Canvas: WebGL (show other bugs)
: unspecified
: x86 Windows XP
: -- normal (vote)
: mozilla16
Assigned To: Benoit Jacob [:bjacob] (mostly away)
: Milan Sreckovic [:milan]
: 730684 (view as bug list)
Depends on: 760415
  Show dependency treegraph
Reported: 2012-06-13 14:14 PDT by Benoit Jacob [:bjacob] (mostly away)
Modified: 2012-08-02 11:10 PDT (History)
8 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

do not create a global context on Windows EGL (2.30 KB, patch)
2012-06-13 16:08 PDT, Benoit Jacob [:bjacob] (mostly away)
no flags Details | Diff | Splinter Review
do not create a global context on Windows EGL (1.27 KB, patch)
2012-06-13 16:31 PDT, Benoit Jacob [:bjacob] (mostly away)
jgilbert: review+
Details | Diff | Splinter Review

Description Benoit Jacob [:bjacob] (mostly away) 2012-06-13 14:14:06 PDT
STR at least on WinXP:
 - go to a webgl page
 - do something that causes the D3D device to get lost. In WinXP, it's enough to lock the screen (Win+L).
 - reload the webgl page

the webgl page should work normally after reloading

upon reloading, webgl context creation fails.

the problem is that in gfx/angle/src/libEGL/Display.cpp, in Display::createOffscreenSurface, at line 682, we have:

    if (testDeviceLost()) 
        if (!restoreLostDevice())
            return EGL_NO_SURFACE;

and in the circumstances reproducing this bug, testDeviceLost() return true here so we bail out with EGL_NO_SURFACE here.

Need a D3D expert to see if there is anything to do here...

Note: this is a follow-up from bug 760415
Comment 1 Benoit Jacob [:bjacob] (mostly away) 2012-06-13 14:42:13 PDT
So, the above code snippet tries to restore the device, and here's where this is failing:

bool Display::restoreLostDevice()
    for (ContextSet::iterator ctx = mContextSet.begin(); ctx != mContextSet.end(); ctx++)
        if ((*ctx)->isResetNotificationEnabled())
            return false;   // If reset notifications have been requested, application must delete all contexts first

Here, isResetNotificationEnabled returns true as we asked to get context loss on reset (EXT_robustness). Anyway, the question is what is this other GL context that is still around here? And the answer is probably the global context --- which we don't make use of on Windows. Let's try disabling it.
Comment 2 Benoit Jacob [:bjacob] (mostly away) 2012-06-13 16:08:16 PDT
Created attachment 632939 [details] [diff] [review]
do not create a global context on Windows EGL

So, this makes it work for me on this WinXP box.

So the GL context that was lying around and preventing resetting the device was indeed the global context. We don't use the global context on Windows EGL at all, do we? I mean, it should have nothing to do with the D3D share handles, right?

This should make the WebGL success rates go up significantly on Windows, as people do keep long-running sessions and if any device loss occurred, without this patch, they couldn't get WebGL anymore until they quit and restarted Firefox. So I would like to backport this to aurora/beta.

This patch also adds some comment around the recently added equivalent line for Android.
Comment 3 Benoit Jacob [:bjacob] (mostly away) 2012-06-13 16:09:01 PDT
Note: the only WinXP specific thing here should be that Win+L loses the device. Similar symptoms should be observable on Win7 when device loss happens.
Comment 4 Benoit Jacob [:bjacob] (mostly away) 2012-06-13 16:31:21 PDT
Created attachment 632950 [details] [diff] [review]
do not create a global context on Windows EGL
Comment 5 Benoit Jacob [:bjacob] (mostly away) 2012-06-13 20:18:48 PDT
Comment 6 Benoit Jacob [:bjacob] (mostly away) 2012-06-14 09:03:19 PDT
Comment 7 Ed Morley [:emorley] 2012-06-15 05:59:50 PDT
Comment 8 Benoit Jacob [:bjacob] (mostly away) 2012-08-02 11:10:40 PDT
*** Bug 730684 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.