AM, Florian Bösch wrote:
On Fri, Aug 24, 2012 at 3:18 AM, Gregg Tavares (社用) <firstname.lastname@example.org> wrote:
Speaking as someone who's developing an application where an arbitrary large number of WebGL canvas could be created, I want to strongly support this second suggestion.
How hard would it be to somehow specify that a "detached" WebGL context can be created, one for which drawing calls with a null framebuffer always fail? Then, gl.bindFramebufer(gl.FRAMEBUFFER, framebuffer_with_attached_canvas) would behave like Florian described.
The only change I would suggest is that instead of overloading framebufferTexture2D, the elegant solution would be to add a framebufferCanvas entry point. This way, it would be possible to eliminate the confusion that would arise from having to pass a texture target.
One possible minimal entry point would be something like
void framebufferCanvas(GLenum target, HTMLCanvasElement element)
This would make it clear that none of the possible parameters in framebufferTexture2D (texture target, attachments, and mipmap levels) are applicable for canvas targets. This call should behave roughly equivalently to creating a plain RTT texture with the right size and attach it to COLOR_ATTACHMENT0.
This is a big change for the spec, so I understand if it would be non-trivial to get right. But it would be absolutely fantastic if you do get it right. I routinely use ~100MB attribute buffers, and guaranteeing that different canvas elements share those attribute buffers would be a huge win.