I've now specced the proposal for this; for details please see this post:
It's not exactly as I was describing earlier, but it's pretty close.
(Turns out what I was proposing has some issues.)
I don't really understand why you would ever do that. Can you elaborate on
On Wed, 14 Nov 2012, Gregg Tavares (社ç~T¨) wrote:
> Why do you want to blow away state? This seems like a perfectly reasonable
> thing to want to do
the use case?
I'm happy to support this if it makes sense, but in practice
I think it's saner not to do that. Complications include things like the
canvas bitmaps being different dimensions from each other (which do you
use? right now I resize the scratch bitmap to match the canvas bitmap),
what happens in the cross-worker case (what bitmap do you draw on, the
previous scratch bitmap, the canvas bitmap?), etc. By clearing the scratch
bitmap and state between each setContext() call, you solve a lot of these
problems cleanly, and it is consistent with what has always happened with
2D canvas whenever the dimensions are changed (which is conceptually
equivalent to binding to a new canvas, IMHO).
Ah, ok. That makes sense. I'd say that it also makes sense to put the
On Wed, 14 Nov 2012, Florian Bösch wrote:
> On Wed, Nov 14, 2012 at 1:03 AM, Ian Hickson <firstname.lastname@example.org> wrote:
> > This question is still important; IMHO the answer to this question is
> > related to where settings that apply to rendering to a specific canvas
> > element's bitmap should be.
> GL contexts map via an affine transform set by the gl.viewport command
> in the form of left, top, width, height.
settings that apply to rendering to a specific canvas on the context too,
The way I specced the proposal for canvas is designed so that it should be
> > My recommendation for WebGL would be to have an explicit method that
> > pushes the bits to the screen, and that would also clear the buffer.
> > So then (c) and (d) couldn't happen.
> I find this a noteworthy idea. Two remarks:
> 1) classically there exists a call in OpenGL called "flip" (which webgl
> does not have) which does exactly that in double buffering situations.
> 2) A call like it on a DrawingBuffer could help to flip exactly that
> drawing buffer you've actually drawn, avoiding to update drawing buffers
> which haven't actually been updated, and avoiding the preserveDrawingBuffer
> mess somewhat.
possible to implement this for WebGL. See the e-mail I cited above for the
hooks that WebGL would need to use to get this working.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'