(no longer active) Reporter
	Description • 12 years ago

See this test case: https://bugzilla.mozilla.org/attachment.cgi?id=632410

Happens on both Mac and Linux.

	Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)
	Comment 1 • 12 years ago

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

	Kelsey Gilbert [:jgilbert]
	Comment 2 • 12 years ago

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

	Kelsey Gilbert [:jgilbert]
	Comment 3 • 12 years ago

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

	Benoit Jacob [:bjacob] (mostly away)
	Comment 4 • 12 years ago

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?

	(no longer active) Reporter
	Comment 5 • 12 years ago

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

	Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)
	Comment 6 • 12 years ago

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

	Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)
	Comment 7 • 12 years ago

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...)

	Benoit Jacob [:bjacob] (mostly away)
	Comment 8 • 12 years ago

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?

	Kelsey Gilbert [:jgilbert]
	Comment 9 • 12 years ago

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.

	Kelsey Gilbert [:jgilbert]
	Comment 10 • 12 years ago

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.

	Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)
	Comment 11 • 12 years ago

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

	Kelsey Gilbert [:jgilbert]
	Comment 12 • 12 years ago

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().

	Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)
	Comment 13 • 12 years ago

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

	Kelsey Gilbert [:jgilbert]
	Comment 14 • 11 years ago

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.