GL20 support

[czyzby]

GL20 implementation should be based on the GWT LibGDX backend and invoke native WebGL methods.

• [x] Typed arrays wrapping.
• [x] WebGL wrapping.
• [x] GL20 implementation based on GWT backend, calling WebGL wrapper.
• [x] WebGLRenderingContext "refactor".

[fpetrola]

We are working with @xpenatan to make improvements on jsDelegateGenerator mechanism that allows easy creation of bridges between java interfaces and js apis such as webgl. https://github.com/dragome/dragome-sdk/pull/65

[xpenatan]

@czyzby I already have alot of gwt backend ported. Just didn't commit yet because im fixing issues for 3d models. If you want to talk more Im always at libgdx irc

[czyzby]

@xpenatan Why don't you make a pull request? There's no point in implementing the same functionalities again and again - I'll just go through what you have, make issues for the missing parts and we'll go from there. I'd like to transfer this repository to dragome/libgdx eventually (once it becomes stable and widely used), so this kind of collaborative work would be nice.

You weren't on the IRC (probably a time zone issue), so I sent you a message through the official LibGDX forum. Make sure to check it out.

@fpetrola It would be really nice if there was a Dragome module that binds native typed arrays and WebGL. Using eval and basically plain-string-based code is a lot more error-prone than strongly typed Java bindings. I think both GWT and TeaVm provide bindings for WebGL, maybe you can base your code on some of that.

[fpetrola]

Totally agree, I think that @xpenatan has made some progress in typed arrays bindings. @czyzby What do you think about creating some unit tests over webgl/typed arrays required functionality to run over dragome and set it as a goal to be compatible enough?

[czyzby]

@fpetrola Well, it can be done, but we'd be testing your binding mechanism (and possibly detect our typos) rather than actual functionalities; we're assuming WebGL works properly in the browser, we just have to bind it, so we can use it directly from Java without eval. I think we can use GL20 implementation from GWT as our goal - we basically have to support all methods that it provides. See https://github.com/libgdx/libgdx/blob/master/backends/gdx-backends-gwt/src/com/badlogic/gdx/backends/gwt/GwtGL20.java

[xpenatan]

@czyzby move to my repo. All this is already resolved in my code =). And I will also port my gwt bullet extension to it.

[czyzby]

@xpenatan I think we just should transfer one of the repos to dragome account right away, @fpetrola did the hardest job implementing the framework. Since this one contains some issues and more stars/watchers (; )), I think that's a good candidate. Maybe Fernando should choose, since we both obviously don't want to give up our repos (duh). For the record, the target account must not have a repository with the same name, or a fork in the same network, so once @dragome contains gdx-dragome or dragome-backend, we'll complete the transfer. Agreed?

(And BTW, you can still make that pull request/commit with your code to this repo, I'd love to look through that and merge with my work already.)

[intrigus]

I'd also like to help, I'll look into bindings to TypedArrays later :)

[czyzby]

@fpetrola @intrigus @xpenatan We should decide whether typed arrays and WebGL wrappers come in an official Dragome module (which would be the logical way to go, but might take more time), or as a part of gdx-dragome.

[fpetrola]

I think we should wait just a bit to know which features are required to make a clean implementation of webgl and typed arrays bindings. For now what @xpenatan has implemented it using the jsDelegateGenerator mechanism which allows to bridge java interfaces to js objects, but this mechanism has some lacks, for example you cannot decided which type of object you are returning in a particular method when the return type is polymorphic or it's just an Object. We should improve the mechanism to let the user configure an strategy to select return type in desired cases.

[fpetrola]

The temporal workaround to lead with this lack is to manually "cast" the returned object to a new JsDelegate using method createFrom(jsObject, type): https://github.com/xpenatan/dragome-backend/blob/master/backends/gdx-backend-dragome/src/com/badlogic/gdx/backends/dragome/DragomeGraphics.java#L55-L60

[czyzby]

@fpetrola Makes sense, we can wait for Dragome features on your end and then continue with GL20 implementation when you release another version/pretty stable snapshot. Anyway, I wouldn't focus on "which features are necessary" - if you plan on making an official WebGL bridge in a Dragome module, it should be complete and support all methods in the standard. Typed arrays are really simple, so pretty much any way of creating, modifying and reading them that you can provide is OK.

[fpetrola]

Official bridge ready! Webgl and typedarrays bridges were implemented.

Both bridges were automatically created using w3c webidl files: webgl webidl typedarrays webidl

They were processed using https://github.com/esrille/esidl and the resulting interfaces were located inside dragome-w3c-standards module. Almost no code is required for implementing these bridges. Most changes were performed in DomHandlerDelegateStrategy which was updated to allow polymorphic getContext result in CanvasElement, as well to handle "set" and "get" methods as array access (array[index]).

Using this automatic approach, Dragome can create any kind of bridge just using WebIDL specifications to create interfaces directly, and performing a tiny setup for typing return values for certain js methods.

[czyzby]

Look into DragomeGL20 class, there are some small issues:

• gl.getParameter(String) has no typed alternatives, which means we have to cast an Object. I think GWT provided typed methods (like getParameterString), making the code a little bit cleaner. I doubt it has any performance overhead, so it is not necessary to "fix".
• methods like uniform4iv require typed arrays or an interface which seems to wrap a simple array. For now, we just copy the values from "native", java arrays to typed arrays, but it would be nice if these method could just consume float[] or int[], kind of like GWT seems to allow. I marked all these invocations with a TODO.

[fpetrola]

Take a look at WebGLRenderingContextExtension class, I've made some (original-class-name)Extension classes to add this kind of custom methods, with this approach we can isolate performance or any custom specific methods into these sub interfaces, and at the same time we are not touching w3c standard api. I think typed getParameter methods should be added to WebGLRenderingContextExtension.

[czyzby]

So I should basically cast the context object into WebGLRenderingContextExtension instead? It's not a problem, but adding these kind of methods to the original context class seems sensible and less confusing (I'm talking about the uniform overloads, not the parameter methods).

[fpetrola]

Agreed, I'll try to change webidl specification file to be able to generate these methods directly.

[czyzby]

As long as the (String)gl.getParameter(name), (Integer)gl.getParameter(name) etc. work correctly, I think this issue can be closed.