webgl: Add getParameter(GL_FRAMEBUFFER_BINDING) support

[anholt]

I've been working on adding support for this getter. Lack of support for it is currently producing a bunch of INVALID_ENUM in unrelated webgl tests due to its use in some shared utility code in the tests. I'm very new to Rust programming, so it's going slowly.

Current code is at:

• https://github.com/anholt/servo/tree/webgl-framebuffer-binding
• https://github.com/anholt/webrender_traits/tree/webgl-framebuffer-binding

(ignore the DO NOT PUSH change in servo, I've been rebasing it out before submission of other patches)

Current questions:

• How does the webrender_traits change get merged safely given that it will produce compile errors in servo until the new enum cases are included?
• What's the right way to wrap my HashMap so that it's mutable at CreateFramebuffer()/DeleteFramebuffer() time, but can still store JS values?
• Is this even the right approach? My HashMap is storing JS<> values, which I think means that they'll keep the WebGLFramebuffers alive for as long as they're present in the hash. The intent of WebGL seems to be that they'd be destroyed by the JS GC (once they're also unbound from their binding points in the GL) This hasn't impacted our other refs because they're only to the current thing in the binding point.

Actually, on the last point: I don't need to be able to map any FramebufferId to a framebuffer, I need to be able to map the current bound framebufferid to a framebuffer. I could track the framebuffer like we do for the current bound program/texture2d/etc!

[emilio]

How does the webrender_traits change get merged safely given that it will produce compile errors in servo until the new enum cases are included?

Servo has a locked dependencies, so it won't break the build.

What's the right way to wrap my HashMap so that it's mutable at CreateFramebuffer()/DeleteFramebuffer() time, but can still store JS values?

Wrapping in a DOMRefCell and calling borrow_mut() is the usual way of doing that.

Is this even the right approach? My HashMap is storing JS<> values, which I think means that they'll keep the WebGLFramebuffers alive for as long as they're present in the hash. The intent of WebGL seems to be that they'd be destroyed by the JS GC (once they're also unbound from their binding points in the GL) This hasn't impacted our other refs because they're only to the current thing in the binding point.

Yeah, that's true... DeleteFramebuffer would need to have some kind of manual refcounting, or something, and that seems like too much churn for this.

Actually, on the last point: I don't need to be able to map any FramebufferId to a framebuffer, I need to be able to map the current bound framebufferid to a framebuffer. I could track the framebuffer like we do for the current bound program/texture2d/etc!

Actually, that sounds a lot more easy, and reasonable :-)