A few questions about the current state of affairs?

[nicolaichuk]

День добрый. Мы gamedev команда. Ищем замену gwt для libgdx.

На данный момент есть два варианта

1) teavm (https://github.com/konsoletyper/teavm/issues/new) + teavm-libgdx (https://github.com/konsoletyper/teavm-libgdx)

2) dragome-sdk (https://github.com/dragome/dragome-sdk) + gdx-dragome-backend (https://github.com/xpenatan/gdx-dragome-backend)

Если судить по номерам версий и первый и второй продукт находятся в стадиях беты.

В описании обоих сравнительный анализ происходит в первую очередь с GWT. Единственный сравнительный материал который удалось найти по "teavm vs dragome" это статью двух-годичной давности https://www.mirkosertic.de/blog/2014/12/gwt-vs-dragome-vs-teavm-for-game-programming/

Можете ли пожалуйста прокомментировать насколько актуальна информация из той статьи на данный момент, а так же что изменилось с тех пор. И возможно какие-нибудь ваши мысли на тему того что все же лучше выбрать в качестве бэкэнда для вебовской версии libgdx учитывая производительность и удобство работы и степени стабильности продукта?

[konsoletyper]

First, on a public resource such as GitHub it's better to discuss in English, in order to allow other users to participate in discussions. If you want to communicate in Russian, you can write to info@teavm.org.

Second, I hope I won't offend you if I translate quoted parts of your original message.

Considering version numbers both products are in beta state

Not true. TeaVM releases are stable, you can use them. You are confused by '0' as a major version number. Well, this means that TeaVM may break backward compatibility between minor releases.

Both (TeaVM and Dragome) are compared to GWT. The only public comparison we could find using "teavm vs dragome" keywords is two year old article https://www.mirkosertic.de/blog/2014/12/gwt-vs-dragome-vs-teavm-for-game-programming/

Can you tell if the provided information is topical and what has changed since then.

I don't know. I don't use Dragome and can't tell how it has changed. Maybe @mirkosertic can tell you. I know that GWT 2.8 has been released and it provided lambdas and other Java 8 features. Also I did some internal benchmarking and could prove that in some cases TeaVM produces much faster code (up to 2x times). This does not mean that TeaVM is always faster than GWT, somebody could find cases when TeaVM is slower, but I don't know anything about that. The only thing I'm sure 100% is TeaVM 0.5.x will be faster than 0.4.x, since it contains some optimizations like inlining and escape analysis/scalar replacement.

TeaVM introduced WebAssembly support recently, which might be very important in gamedev. Also, I made some experimentations with LLVM and could translate some Java apps to native binaries, but currently I have no time to maintain LLVM backend.

and probably some thougths about what to choose to create backend for web version of libGDX backend, considering performance, convenience and stability.

I repeat, I don't know anything about Dragome. AFAIK, it's slower than TeaVM, at least according to Mirko Sertic's demos for Game Composer.

I can tell that TeaVM's main priority is to produce small JS output. TeaVM performs some sort of global data-flow analysis to remove unused code, this produces fantastic result. However, this makes implementing reflection virtually impossible, so TeaVM supports only small subset of reflection API. In opposite, Dragome claims to support reflection API completely. As for me, reflection is not necessary. It's often possible to avoid reflection. This makes impossible to compile libGDX as is, but it's possible to make small patches to libGDX in order to make it compatible with libGDX. Can tell what are important use-cases for reflection? I could create a powerful web framework with data binding, serialization and REST client without a line of reflection. TeaVM provides its own API for compile-time programming, very similar to GWT generators.

As for stability, you can always ask me to fix bugs. If your project becomes successfull, TeaVM becomes successfull too, so have a great motivation to help these projects.

[nicolaichuk]

Thank you for the detailed response. My English is not very good, and I could not find your email for correspondence.

I sent you a mail on info@teavm.org

[mirkosertic]

Hey,

I've been on vacation the past days. Here are my experiences with Dragome SDK:

• Supports Java 8 incl. Reflection
• Not as fast as GWT and TeaVM in my use case(GameEngine)
• Compiler is really slow, as it is backed by XMLVM
• Resulting JS can be huge, as Dragome Runtime has to support reflection, thus unable to use compile time dependencies to remove unused code and do other optimizations
• No WebAssembly support

For my GameEngine project, I deprecated the Dragome and GWT parts. For details, please visit https://www.mirkosertic.de/blog/2014/12/gwt-vs-dragome-vs-teavm-for-game-programming or https://github.com/mirkosertic/GameComposer

[nicolaichuk]

@mirkosertic, Thank you for your reply.

Our team decided to use Dragome. Because it have better supports reflection and have gdx-bullet implimentation. Perhaps then we will try to use TeaVM for compare performance.

@xpenatan, @fpetrola: Maybe you can add something to this discussion?

P.S.: https://github.com/xpenatan/gdx-dragome-backend/issues/13

[mirkosertic]

Ok.

Here a sidenote: I used TeaVM with http://www.pixijs.com with great success. Then you get full WebGL/Shader support with HTML5 Canvas Fallback. Howler.js is a great Web Audio API which also works perfectly with TeaVM.

If you need a 2D physics simulation, I used JBox2D with TeaVM also in some demos.

So TeaVM, PixiIS, HowlerJS and JBox2D are a great combo for game programming :-)

You can't go faster. Here is a simple Demo:

https://mirkosertic.github.io/GameComposer/games/teavm/platformer/index.html

[nicolaichuk]

@mirkosertic:

If you need a 2D physics simulation

No. We need 3D physics, artemis-odb, libGDX and bdx )

[xpenatan]

Compiler is really slow, as it is backed by XMLVM

Dont know when you tested. All demos in my repo (including my editor) takes 5-6 sec to compile.

[fpetrola]

Hi! That comparison is from 2014, Dragome has evolved a lot since then. An even on that old comparison Dragome performs almost the same as the others when checking cast is enabled and disabling check cast it's as faster as competitors.

Hey,

I've been on vacation the past days. Here are my experiences with Dragome SDK:

Supports Java 8 incl. Reflection

Reflection now includes Annotations and even Google Guice can be used as dependency injection provider using exactly the same code of desktop java app.

Not as fast as GWT and TeaVM in my use case(GameEngine)

Depends on checking cast is enabled or not. Checking casts is required for some kind of applications that relies on catching clauses for its control flow. But if it's not your case you can disable it.

Compiler is really slow, as it is backed by XMLVM

It's not backed only by xmlvm, it's backed mainly by a modified version of j2js compiler. You should test it again, there are several optimization applied since 2014. Nevertheless in '14 comparison it was performing a lot faster than GWT, in '17 version with remove unused code and obfuscation it's really faster than initial comparison.

Resulting JS can be huge, as Dragome Runtime has to support reflection, thus unable to use compile time dependencies to remove unused code and do other optimizations

Current Dragome version supports Proguard features, including unused code removal (shrink), obfuscation, inline methods, etc. If you know how to use Proguard you can do everything you want to optimize your final code.

No WebAssembly support For my GameEngine project, I deprecated the Dragome and GWT parts. For details, please visit https://www.mirkosertic.de/blog/2014/12/gwt-vs-dragome-vs-teavm-for-game-programming or https://github.com/mirkosertic/GameComposer

[nicolaichuk]

@fpetrola: Compiler is really slow, as it is backed by XMLVM

@xpenatan: Dont know when you tested. All demos in my repo (including my editor) takes 5-6 sec to compile.

If speak about gdx-dragome-backend:

Build statistic for our app:

20:19:24.389:INFO::Started SelectChannelConnector@0.0.0.0:8080
######################## ClassPath Order ########################
....
#############################################################
Compiling classes: ....
Compiled classes: 3189
Total compile time: 00:03:57.150
----------------------------------------------------------------------
DRAGOME BUILD SUCCESSFUL: js application ready
----------------------------------------------------------------------
Finished at: 20:25:59

Compile about 3 thousand classes it took about 4 minutes.

If calculate time with process filter it took about 7 minutes. As I say here - many work is doing using one thread (and total cpu used less than 10%).

Result size generate webapp.js+webapp-1.js about 19Mb.

It was debug build without remove unused code and with disable obfuscation.

But I do not know how long it would take time with Teavm. Maybe less, maybe more.

[fpetrola]

I'm sure it's a dragome compiler bug that arises on your specific compilation, it takes 24s for 2375 classes in my machine:

#################################################################
Compiling classes: ..............

Compiled classes: 2375
Total compile time: 00:00:24.046
----------------------------------------------------------------------
DRAGOME BUILD SUCCESSFUL: js application ready
----------------------------------------------------------------------
Finished at: Thu Mar 2 15:45:29 ART 2017
======================================================================

[fpetrola]

Let's follow this issue, and try to reproduce it on github dragome tracker.

[xpenatan]

@nicolaichuk are you using gradle?

compiling all classes.

multi-threaded will probably reduce it alot

[nicolaichuk]

@xpenatan I try gradle with gretty and only eclipse jetty plugin - both result equal.