I’ve been using some time recently to learn WebGL and cross platform development with Kotlin. Ultimately I want to be able to use OPENRNDR in the browser, and maybe as a native compiled code in the future. I learned that cross platform Kotlin libraries have to adhere to certain standards. For example there should be no dependency on standard Java libraries, so no java.lang.Math, StrictMath, no Serializable.
I made a small experiment to compile openrndr-math to JavaScript:
It worked and I can actually already start doing some nice creative coding experiments just with openrndr-math. But I had to do some small modifications, and I was not sure how to solve some issues, so I commented out part of the code. I also moved to kotlin native serialization. Here is the commit with all the modifications:
The JavaScript output is around 5kB after advanced optimizations and dead code removal with google closure compiler:
@edwin I would be interested in your opinion on how it can be pushed forward and if you think it’s realistic to change the code and packaging of some OPENRNDR modules to make them “Pure Kotlin” and cross platform?
I will get back to this in more detail later. I’d love to support your effort! I think this requires some serious rethinking/reworking of how OPENRNDR is organized. I expect this can be done progressively.
My gut feeling is that going for pure Kotlin is the way to go, but it may not always be entirely possible. I believe there are also ways to split up modules into -common, -jvm and -js parts.
Yes, it’s possible to do such a module split. If not for the actual code if there is no need for it, it might be worth somehow to do it for testing, to force running the same unit tests on all the platforms involved. I will research it further taking openrndr-math as a playground. I will also research to which extent kotlinx.serialization is a functional replacement for standard java serialization.
I updated the test project to make it a multiplatform library project:
I will try to use it first a bit as a library, to see how much dependency management is changing with libraries defined this way, it seems that at least some ‘jvm’, ‘js’, etc, qualifier might need to be added, which would break down compatibility. I also want to see how to do proper unit testing. If nothing breaks, I can try to do pull request out of it as a first step in “multiplatform OPENRNDR” direction.
Most of the utility code in openrndr-math, openrndr-shape, openrndr-color, openrndr-animatable and openrndr-event is already compiling using common / js / jvm interfaces.
Parts of the WebGL back-end are in place and in somewhat working condition.