JMonkey and GWT

Hi guys,

I recently came across WebGL, a javascript → opengl binding for modern browsers. I also found gwtgl (, a way for google’s gwt to compile java opengl code to javascript.

My question is that if it is possible (or desirable) to have a gwt compatible version of jME, so that any application written for jME can cross-compiled to javascript. Maybe this could be an interesting project?

There is a project that has successfully converted jake2 to run under gwt (, so at least what I am suggesting is doable in theory.

What are your thoughts, master monkeys :slight_smile:

Thanks, we know about this and maybe at some point we will look into this, right now its not of much interest but when/if WebGL gains traction this might be an interesting migration path. Threading and some other stuff jME3 uses doesn’t work with GWT so its definitely not just a one-click compile.

Perhaps when WebGL gets wider support we will consider this. However at this point it seems unfeasible from the point of performance and the limitations of GWT.

Thanks guys for the replies.

All major browsers (with the exception of IE) support webgl out of the box, this could be a game changer (i.e. 3D web) in the next couple of years. So being the big monkey fan that I am, I thought this could be an interesting way to make JMonkeyEngine more ubiquitous.

As far as performance is concerned, the major bottleneck with webgl I believe would be the speed of the javascript. Since WebGL has access to shaders, the graphics performance should not be too bad, provided that the javascript can keep up. Not sure about the limitation of GWT as I have very little experience with it.

@normen: A little off-topic, but I am currently working on porting my app ( to jME3 and I do noticed that jME3 spawns its own thread for GL rendering right away. For my purpose, I actually had to make it back to a single-threading model (since I want my users to create their own threads). So what I did was create my own context in Application and call “context.runLoop()”. Do you foresee any problems with this? Or should I take a different approach? I could provide more details if the above explanation is not clear.


batkid said:
Do you foresee any problems with this? Or should I take a different approach? I could provide more details if the above explanation is not clear.

Yeah, you shouldn't depend on accessing the OpenGL subsystem directly. The jME3 API abstracts all that so we can flexibly adapt and extend the engine and performance (also for different platforms, multithreading etc.). So its strongly discouraged to go "outside" the jME API and update loop model. If you think you cannot do what you want tell us how we might improve the API to allow it and we will look into it. Multithreading should in any instance be bound to the update loop, anything else is a mess (think creating Callables/Futures and checking them in each loop tick).

This is going off-topic a little, so feel free to split this thread…

Here is my problem. For my application, which is a wrapper to jME, it is designed to be simple to use by beginners to Java programming.

Since these are beginners, I want to avoid discussing threads until much later, and when that happens, I actually want students to create their own threads. That’s why I needed to hack jME back to a single thread model.

In order to do that, I extends lwjglDisplay like this:


public class EnvDisplay extends LwjglDisplay{


public void create(boolean waitFor) {





Basically, I bypassed the creation of the thread by calling initInThread() in my own create method.

Then in my Application class, I called context.runLoop() manually.

At this point, I only want to target lwjgl as the renderer. Would this cause compatibility problems down the line since I’m simply extending from LwjglDisplay?