User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100920 Firefox/4.0b7pre Build Identifier: 20100920123427 Go to the URL given. Click on the second demo, Blob. When it's running either resize the window or move it. My system freezes on me. Getting into Task Manager using Ctrl-Alt-Del get's things going again so you can exit Fx. I'm on W7 x64. HW acceleration is on. Reproducible: Always

i see the same pasting a quick link to the case http://webglsamples.googlecode.com/hg/blob/blob.html just moving the window will freeze the browser until you push Ctrl-Alt-Del that will revive it

http://webglsamples.googlecode.com/hg/caves/caves.html doesn't display anything

Confirmed on fresh profile, Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100920 Firefox/4.0b7pre.latest hourly: http://hg.mozilla.org/mozilla-central/rev/573b9178b897Disabling JM or TM or D2D or layers or both wont resolve the problem.

(In reply to comment #2) > http://webglsamples.googlecode.com/hg/caves/caves.html > > doesn't display anything Actually I got it working once a little while ago. Hung up but not Fx or the system. Now all I get is a red box where the Caves should be.

Maybe you should CC Boris and Benoit from Bug 596544 .

(In reply to comment #2) > http://webglsamples.googlecode.com/hg/caves/caves.html > > doesn't display anything We've discussed the Caves demo on the public webgl list, with the author. It seems to have a race condition preventing it to load correctly. But if you refresh a couple of times, and are lucky, it will show up properly. Anyway, not our bug (only working "by accident" in Chrome) as far as we can see.

(In reply to comment #0) > User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) > Gecko/20100920 Firefox/4.0b7pre > Build Identifier: 20100920123427 > > Go to the URL given. Click on the second demo, Blob. When it's running either > resize the window or move it. My system freezes on me. Getting into Task > Manager using Ctrl-Alt-Del get's things going again so you can exit Fx. I'm on > W7 x64. > > HW acceleration is on. > > Reproducible: Always Hm, can't reproduce under linux with GL layers. Rebooting in windows to check...

OK, it's easy indeed to reproduce on Windows. What was harder was to be able to get to the MSVC UI to debug into it... here's a dump. It shows thread waiting or polling. So it's looking like a deadlock. I can't see much relevant from a WebGL / graphics point of view. Sometimes it unfreezes on its own after a while.

Confirming that the hang happens only with 64 bit Firefox. Because of that, it won't be handled in priority (we don't aim to support 64 bit Firefox builds under Windows officially in 4.0. But we do support running 32 bit builds under Win64).

I'm running 32 bit Fx4 on Windows 7 x64.

Ah! Then this is suddenly much more critical! Let's see if the Graphics people have something to say about it.

This certainly sounds confirmed.

D2D/D3D9 on/off make no difference here, symptoms are always the same. Interestingly it resumed rendering just fine if you alt+tab away and then back in. I haven't done much diagnostic work yet so I've got no idea what's causing it.

it works fine for me on chrome canary. but on firefox, for somereason i get the following message : This page requires a browser that supports WebGL. Click here to upgrade your browser. is WebGL turnd off on intel gfx ?

I'm running a 32 bit Firefox on 64 bit Windows, and have the problem. As I mentioned in comment 3, disabling JM or TM or D2D or layers or both wont resolve the problem. It also freezes when you resize the window. Not when you use maximize, etc buttons, but when you drag the window's borders to resize. Gary should rename the bug to add this.

(In reply to comment #14) > it works fine for me on chrome canary. but on firefox, for somereason i get the > following message : > This page requires a browser that supports WebGL. > Click here to upgrade your browser. > is WebGL turnd off on intel gfx ? It was until yesterday, so the latest nightly should allow you to do WebGL. But be advised that due to **** openGL drivers on windows, intel gfx are potentially buggy there. In Chrome, they use Direct3D via ANGLE for that, and that's what we're going to do too, soonish.

I am running FF 32-bit on Win 7 64-bit with Intel gfx : I have the same problem. Setting layers.shader_validator to false solves the problem. I think it is a dupe of bug 594387.

(In reply to comment #17) > Setting layers.shader_validator to false solves the problem. OOOh. Great catch !!

OK, not sure yet if it's a dupe of bug 594387. But both are definitely going to be ANGLE issues. It could be worth checking if bugs have been fixed in ANGLE lately and updating. It could also be worth making ANGLE bug reports but for that we need to narrow it down to the particular shader that's causing issues. We also need to figure if the problem is in ANGLE itself or in the way we're using it.

What problem? If i set that key to false, (and restart Minefield to set the changes) the Blob demo still hangs the system when i resize or move the window. And it generates massive memory consumption (230MB), but i think that's another bug.

Comment 17 was wrong. After a new try, I can reproduce the issue with layers.shader_validator to false. Other causes of hang with this demo : * resizing of FF window * moving of Error console window

Correct, you have exactly the same issue as me. Disabling JM or TM or D2D or layers or both dont resolve the problem.

I added a Windbg log. But I don't think it is useful, because when system hang, going back to Windbg window requires a ALT+TAB key that stops hang.

So, I have news. Using the verbose debug mode from Bug 597881, I realized that while it is "frozen", it is actually continuing issuing lots and lots of GL calls. So my best guess is that Windows' own compositing engine (which is stressed when we move the window around), which is using shaders too, is not playing well with shader-intensive OpenGL code. In this case, the explanation why Chrome is not affected would be that they use Direct3D for rendering on Windows, as we soon will (looks like we don't have a choice).

It means that D3D rendering via ANGLE for WebGL will block 4.0 final?

Switching to Windows Classic theme seems to make it a bit better, but I can still reproduce the problem (trying a bit longer). But it seems to me that Windows Classic is still composited, e.g. how else could it render the blue shade when about to maximize a window.

(In reply to comment #26) > It means that D3D rendering via ANGLE for WebGL will block 4.0 final? It means that it's becoming a bigger priority than expected. I need to discuss this with other people.

Here's a small self-contained test case! All it does is repeatedly call gl.clear() and gl.finish() a thousand times per render() call. And render() is called by a setInterval with 1 ms interval. So it's just hogging the GPU's fillrate. When I move the firefox window, Windows 7 freezes and locks the mouse pointer so I can't get to the taskbar. Pressing Ctrl+Alt+Delete restores normal operation.

Time to ask what graphics card is everybody using? I have a NVIDIA quadro FX 880M. Scoobidiver do you confirm that it's on a Intel card that you can reproduce the problem? 2 different vendors would rule out a driver issue...

> setInterval with 1 ms interval. So a 10ms interval, due to the clamping. Just in case it matters.

Here's a better testcase: - not calling clear/finish 1000 times per render() anymore. Just calling it once, but instead we do a very expensive JS loop. So we don't hog the GPU anymoe, we hog the CPU (in Firefox's process). - not using a "FPS counter" HTML element anymore. Now there is only a webgl canvas in this page, nothing else. Also, setting setInterval to 10 ms :-) it didn't matter.

> Scoobidiver do you confirm that it's on a Intel card that you can reproduce the > problem? Yes, Intel GMA 4500MHD, graphic driver : 8.15.10.2202 > Here's a better testcase: With the minimal testcase, I can reproduce the system hang when I move the FF window.

Actually this whole bug has nothing to do with Canvas / WebGL / OpenGL / whatever !! Look at this new testcase, all it does is set up a setInterval timer that runs a big JS loop everytime it ticks. Load this page, then move your window around, it should freeze Windows in the sense that it won't respond to your clicks, and will also constrain your mouse pointer above the taskbar; exit by pressing Ctrl+Alt+Del. How should this bug be retagged now? It's clearly a Windows bug that an app may freeze it just by being a CPU hog, but I guess that we could do something to work around it... is it the case that Windows expects apps to respond to "messages" or "events" when their main window is being moved??

> is it the case that Windows expects apps to respond to > "messages" or "events" when their main window is being moved?? Or resized, iirc... ccing some folks who might know something about the Windows move/resize event loop.

I think Felipe is looking into another bug where we freeze while resizing on Windows, maybe the same thing.

(In reply to comment #34) > is it the case that Windows expects apps to respond to > "messages" or "events" when their main window is being moved?? Normally window resizing is handled by the window's thread. In particular if the thread responds to the mouse click then the window border and title bar resizing is all done in-process, so you can't interact with the window if the thread stops responding during the drag. The thread also captures the pointer but as you noticed this only lasts as long as the window has focus.

This looks like a dupe of bug 575515 to me.