[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Sharing Resources across contexts
So I ran into my first issue prototyping this. Ideally checkFramebufferStatus will return FRAMEBUFFER_INCOMPLETE_ATTACHMENT if an attachment is not acquired but... if you're only going to read from a framebuffer (calling readPixels) you should only need READ_ONLY permission where as if you are going to draw to the framebuffer (clear/drawArrays/drawElements) you need EXCLUSIVE permission. Since checkFramebufferStatus doesn't know your intent it can't give you the correct answer.
Several solutions came up so far.
1) Require EXCLUSIVE permission for framebuffer attachments
That's not really a solution since one of the required use cases is multiple workers reading from the same texture.
2) checkFramebufferStatus assumes READ_ONLY permission only
That means you might still get a INVALID_FRAMEBUFFER_OPERATION if you acquired attachments for READ_ONLY access and then try to draw.
3) expose the DRAW_FRAMEBUFFER and READ_FRAMEBUFFER bind targets
On systems that support multi-sampling there are 2 framebuffer bind targets. DRAW_FRAMEBUFFER and READ_FRAMEBUFFER. DRAW is where drawing happens. READ is where reading happens. Unfortunately since multi-sampling isn't supported everywhere allowing you to bind separate framebuffers to DRAW_FRAMEBUFFER and READ_FRAMEBUFFER won't work.
4) allow DRAW_FRAMEBUFFER and READ_FRAMEBUFFER as arguments to checkFramebufferStatus
In this case you'd still only be able to bind to gl.FRAMEBUFFER but you can call checkFramebufferStatus with either DRAW_FRAMEBUFFER or READ_FRAMEBUFFER or FRAMEBUFFER. The OpenGL spec defines FRAMEBUFFER as meaning both READ_FRAMEBUFFER and DRAW_FRAMEBUFFER so this proposal would just work and be future compatible.
In other words.
gl.checkFramebufferStatus(gl.FRAMEBUFFER) // checks for EXCLUSIVE access
gl.checkFramebufferStatus(gl.DRAW_FRAMEBUFFER) // checks for EXCLUSIVE access
gl.checkFramebufferStatus(gl.READ_FRAMEBUFFER) // checks for READ_ONLY access
#4 seems like the best/correct choice but I thought see if there were other ideas.