Open ptxmac opened 1 year ago
Thanks for the detailed report Peter.
I haven't used it in a while (but I'm planning to next year), but another solution that comes to mind, to preserve the interchangeability between Go's nil and JS's Null, would be changing the .JSValue()
method to convert nil to the a js.Null
. So the line below would work:
func (_this *RenderingContext) BindFramebuffer(target uint, framebuffer *Framebuffer) {
...
_p1 := framebuffer.JSValue()
...
What do you think ? Would that work ?
I think that's more or less what I meant with my 3rd suggestion. I.e. from the users perspective, it would look like the following?
gl.BindFramebuffer(webgl.FRAMEBUFFER, nil)
(edited)
So you're suggesting making a change like this?
func (_this *Object) JSValue() js.Value {
+ if this == nil {
+ return js.Null()
+ }
return _this.Value_JS
}
Looks good to me, I can't think of any time where a panic is preferred to js.Null 😄
The only thing to be mindful of is null
vs undefined
- I don't think there's anywhere in WebGL where you would use undefined, but that's a little outside my experience
Yes, that's what I had in mind.
I'm also no JavaScript expert, so I don't have an opinion on the null
vs undefined
choice. But as you said, better than panic.
Do you want to write the PR ? I'll approve it. I would just ask to add a line of comment on the JSValue() method about nil
being converted to null
in JavaScript.
Do you want to write the PR ? I'll approve it. I would just ask to add a line of comment on the JSValue() method about
nil
being converted tonull
in JavaScript.
Yup, I'll take a stab at it
Created the first attempt in https://github.com/gowebapi/webidl-bind/pull/11
This can now be resolved if the files are re-generated
@janpfeifer could to re-generate the files?
(Or should I create a PR with it?)
hi @ptxmac, sorry I missed it. I was hoping you would re-generate the files as well. I only did it once, > 1 year ago, I would have to investigate how to do it.
I'm currently finishing a different project that doesn't use gowebapi
. I'm planning to get back to it next year, in a couple of months.
A typical pattern in WebGL is to bind a "null" value.
E.g.
gl.bindFramebuffer(gl.FRAMEBUFFER, null);
According to the documentation, this is how to reset the current FBO back to the canvas:
Because of how the types are implemented in WebGL, this is not elegant to do
Preferred pattern:
Unfortunately this will panic
Problem
From
webgl_js.go
:In the case of
js.Null()
this returns a nil pointer, which we try to pass toBindFramebuffer
Unfortunately, this code expected a non-nil
Framebuffer
, and will panicWorkaround
It's possible to work around it by manually creating the
Framebuffer
object, but it's not elegant:Solutions
I can think of a couple of solutions:
IsNull
check from the*FromJS
methods and allow the creation of null objects.gl.BindFramebuffer(webgl.FRAMEBUFFER, webgl.FramebufferFromJS(js.Null()))
Null
versions of objects.gl.BindFramebuffer(webgl.FRAMEBUFFER, webgl.NullFramebuffer)
nil
tojs.Null
gl.BindFramebuffer(webgl.FRAMEBUFFER, nil)
Notes
From my OpenGL understanding this pattern is used for all objects. I.e. all
Bind*
andUse*
methods (gl.bindTexture/gl.useProgram/gl.bindBuffer
etc)The mozdev webgl documentation is unfortunately a little lacking, and only framebuffers are explicitly mentioned to be null - but I assume it also holds true for any other objects