gowebapi / webapi

Go Lang Web Assembly bindings for DOM, HTML etc
BSD 3-Clause "New" or "Revised" License
174 stars 12 forks source link

RFE Include WebVR #1

Closed ghost closed 5 years ago

ghost commented 5 years ago

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:

    canvas := webapi.GetWindow().Document().CreateElement("canvas", &webapi.Union{js.ValueOf("dom.Node")})
    canvas.SetId("mycanvas")
app.AppendChild(&canvas.Node)

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

ghost commented 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?

https://github.com/WhiteHexagon/example-gowebapi-webgl

martin-juhlin commented 5 years ago

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?

ghost commented 5 years ago

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. this seems to make porting code between bindings, or from C examples a lot easier. At least they are already uppercase :) I'm trying some ideas for enum grouping, but nothing satisfactory so far...

Thanks for adding the WebVR binding!

ghost commented 5 years ago

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", "")
    }
martin-juhlin commented 5 years ago

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.

ghost commented 5 years ago

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.

martin-juhlin commented 5 years ago

This issue is now consider solved. Thank for the feedback! :-)