On 10/22/2012 1:42 PM, Gregg Tavares (社用) wrote:
Fair enough, I suppose gl.canvas can just switch around to point at the current one. That would at least let libraries treat the gl object in a consistent way regardless of how many canvases the developer is drawing to.
We already have a special case where these all fail -- where the framebuffer is the special object 'null'. It's really just extending that special case...
This feels a lot more confusing to me -- we already have framebuffer machinery that's well defined, and the current framebuffer is conceptually "where rendering goes". Introducing new API for switching canvases seems like it would just add an unnecessary layer to this. Additionally, if we do, then in the future we'll always have to consider our canvas-targetting functions for how they interact with extensions, etc. If we just define canvases to be framebuffers, and use the regular framebuffer approach, then we reduce the amount of work going forward. It feels much cleaner to me, and a lot less developer-thought required ("Which framebuffer is bound? That's where drawing is going." vs. "Which framebuffer is bound and which canvas is bound? Is the framebuffer null? Ok then it's going to the currently bound canvas, otherwise it's going to the currently bound framebuffer.")