Closed ghost closed 5 years ago
I got something running for the WebGL stuff :) but I am not sure if the approach is correct. It seems a bit difficult to identify the correct enums from the interface, but that seems to be the same within the .IDL file, so probably nothing can be done about that. But maybe the '_WebGLRenderingContext' could be removed?
Hi! I have added WebVR 1.1 specification.
Nice of you to do some testing with, it help finding odd stuff that the generator is doing. When it comes to the enum, most of them is defined as constant in the IDL. But if we do group them into enums, is every constant used in that way that they can belong to just one enum?
Can I use your program as an example in the godoc?
Sure :) So I captured the example into a separate repo, since I already diverged from the original for some custom wrappers. So the new repo is at:
https://github.com/WhiteHexagon/example-gowebapi-webgl
Having worked with other GL bindings, the common approach is that all enums are just accessed via gl.
Thanks for adding the WebVR binding!
PS for anyone else searching, this is what I found on fullscreen support:
if elem.Get("requestFullscreen") != js.Undefined() {
elem.Call("requestFullscreen", "")
} else if elem.Get("mozRequestFullScreen") != js.Undefined() { /* Firefox */
elem.Call("mozRequestFullScreen", "")
} else if elem.Get("webkitRequestFullscreen") != js.Undefined() { /* Chrome, Safari and Opera */
elem.Call("webkitRequestFullscreen", "")
} else if elem.Get("msRequestFullscreen") != js.Undefined() { /* IE/Edge */
elem.Call("msRequestFullscreen", "")
}
I have done a clean up of the webgl and webgl2 api. Changed redundant "webgl.WebGL" to just "webgl.". Constant doesn't have WebGLRendererContent any more and fixed the missing in the constants. I also copied the fullscreen code in a dom.Element.RequestFullscreenByBrowser() method.
Looks good! I updated the demo. I came to the same conclusions with my own mini hand-crafted wrapper (just enough for the same demo). I also added some grouping on the constants, but I'm not sure it adds much. I'm also wondering if the overhead of all the required js.Call calls is too much (at least for WebGL, probably irrelevant for all the other APIs). It's a shame WebGL doesnt yet exist as pure wasm modules that we could call directly from go wasm! In the meantime I'm just looking at threejs, which would reduce some of the js call overhead since the js API is at a higher level.
This issue is now consider solved. Thank for the feedback! :-)
I'm very happy to find your project here. I was just about to try and write myself a WebIDL parser to do exactly this, so well done and thanks.
Anyway I'm not sure the best way to provide feedback? Basically I'm wanting to do some WebGL (v1) via Go/WASM, and hopefully from that also include WebVR support. I can see that you have WebXR support, but there are not many browsers supporting that so far. Do you have any plans to add WebVR?
So far I managed to get my Go WASM creating a 'canvas' element:
And finally, I can see that you have some full screen support in dom.go, but I cant see a method to requestFullscreen() or am I missing something obvious there?
Sorry to ask so many questions, and keep up the good work!
macos10.12.4 go1.12