Cheerp3 web interface slow

[mmkathurima]

The newer Cheerp3 web interface takes too long to load.

[reportmill]

I have a great fix for this, but I can't implement it until they add support for JNI to CJ3 (which they say is coming soon).

Once they add JNI, I can change all the graphics to use Web APIs (HTMLCanvas, CanvasRenderingContext2D, WebGL, etc.). Because this will eliminate the dependency on Swing, this should have dramatic effects:

• Cut download size in half
• Double rendering speed
• Allow for more threading opportunities (image loading)
• Provide real 3D support (WebGL)

This version will also feel more like a web app, as opposed to a Swing app running in a frame, since windows won't be constrained to the CheerpJ Swing virtual display.

Check out the TeaVM version for reference. The cold launch time is just a second or two (hot launch time is sub-second), and the general response time is instant. And it's a much nicer looking experience.

https://reportmill.com/SnapCode/app/

[mmkathurima]

@reportmill Speaking of your fix, does it mean that your codebase will undergo (major) refactoring or entirely be rewritten once you are able to migrate to cj3?

[reportmill]

No, all the existing code will be exactly the same. I will simply have to update two external projects (in my CJDom and SnapCJ GitHub repos). Those (CheerpJ 2) projects map Web APIs to Java (CJDom) and SnapKit APIs to those Java APIs (SnapCJ). Once those are done, there will be 2 options to run SnapCode in the browser, either using Swing or the Web APIs (the second being the much better choice). I should be able to get something working in a week. And then be mostly done in a few weeks.

The good news is that the CheerpJ guys just told me they are starting the JNI work next week!

Just as well - adding support for MethodRefs has taken me longer than I thought. I'm having to update my lambda support to use the new Java reflection APIs (java.lang.invoke.MethodHandle instead of java.lang.reflect.Method). Hoping to be done with that today or tomorrow.

[mmkathurima]

Will cj3 web APIs still be capable of running as a desktop jar application similar to the current Swing application?

[reportmill]

Yep, the exact same jar will run with Swing on the desktop, and with native Web APIs in the browser (or Swing, if you want, since CJ supports Swing in the browser).

SnapCode is build with my SnapKit UI library which is much like a modern Swing, but it abstracts all the painting and windowing (and other things like images, fonts, user events, clipboard and drag and drop). The Swing adapter for this maps all that abstract API to Swing/Java2D APIs (Graphics2D, BufferedImage, etc.). The SnapCJ adapter (or SnapTV adapter for TeaVM) maps those APIs to browser Web API (HTMLCanvasElement, CanvasRenderingContext2D, etc.). I used to even have a JavaFX adapter, but it didn't provide any real benefit over Swing, so I dropped it.

But the net effect is that the app can determine where it is running when launched (desktop or browser) and use the best adapter dynamically (by looking at the Java "os.name" property) to get the best results.

It's not near as complicated as it sounds - SnapKit is actually pretty small (but complete).

[reportmill]

By the way, I do plan to generate a "native desktop app package", so you can get SnapCode as a .app/.exe for Mac/Windows/Linux. This is easy to do using jdeploy.com (should only take a few hours), but I haven't gotten to it yet.

[reportmill]

Lots of improvements to web interface in 3 weeks! All interface elements and drawing now done with native DOM in browser. So much faster drawing, more native look, support for HiDPI/Retina, support for WebGL.

The CheerpJ guys have improved performance as well. And they will improve in the weeks and months to come. First launch can take ~30 seconds, but successive launches are ~3 seconds.