See this test case: https://bugzilla.mozilla.org/attachment.cgi?id=632410 Happens on both Mac and Linux.

And on Win32. This is bad; we need to figure this out.

This is very likely to be preserveDrawingBuffer:false acting up. I don't know how much we can do within spec.

This needs a testcase for testing if this is still an issue for pDB:true.

I thought that the spec had been clarified so that it no longer implies that preserveDrawingBuffer=false's semantics should depend on this sort of thing?

(In reply to Jeff Gilbert [:jgilbert] from comment #3) > This needs a testcase for testing if this is still an issue for pDB:true. Does the testcase in comment 0 do the job?

Here's a simple test. Indeed, preserveDrawingBuffer: true "fixes" this. The issue is that alert() ends up giving up control back to the browser, so our regular semantics of clearing because we happen to composite the contents at that point come into effect. I think Jeff's right; there isn't anything that we can do here (or should). We should raise this on the WebGL list though, and clarify preserveDrawingBuffer behaviour in light of synchronous calls that go back into the browser's event loop...

Though actually.... that means that it will be impossible to break in WebGL-drawing code without pDB: true, because the compositor will run while JS is stopped. So maybe we do need to figure out a fix here, or we can just tell people that they have to debug with pDB = true? (And perhaps detect outstanding webgl contexts in the debugger that have pdB = false and print a warning...)

The WebGL spec has already been clarified recently, if I remember correctly, for exactly this kind of problem. What part of the current spec do you think is still unclear?

We currently operate under the assumption that if we're executing on the main thread, we're not in the middle of JS execution. It sounds like this isn't actually true. As such, we need to prevent presenting our buffer until we actually return from JS code. I don't know how to do this in the general case. This sounds like a question for the JS guys.

Luke says that alert() spins a nested event loop, as opposed to the base-level event loop. We're probably compositing in this nested loop, clearing the framebuffer, and rendering the second half the frame (after the alert()) before presenting this half-frame for rendering. We need a way to query whether we're still in the middle of JS execution. bsmedberg is said to know more.

What does the rest of the platform do? E.g. if you're moving around a bunch of stuff by adjusting their CSS values and you alert(), do you see the "current" values or the old ones? I suspect current. Not sure that the expense of "fixing" this for WebGL is worth it...

I propose downgrading this to p2 or p3, since alert() shouldn't really be used mid-frame outside of debugging. Even still, debugging should probably be using console.log() instead of alert().

Yep, I agree. Feel free to unassign yourself from it, too, now that we have a better idea what's going on.

This works since the streaming buffer stuff landed, which gave us proper front/back buffers for webgl content. The testcase still shows the preserveDrawingBuffer:false case Presenting its black cleared buffer after a call to gl.clear(DEPTH_BIT). However, this is what the spec dictates, even though the clear() cannot possibly change the pixels in the color buffer. We could change the spec, but I don't think it's probably worth the effort.