OPENRNDR: creative coding and real-time graphics on the JVM

A library for people who write programs that draw

The description is one line and it is precise: a Kotlin and JVM library for creative coding, real-time and interactive graphics. The readme expands it slightly to a Kotlin and JVM and Kotlin and JS library, and says it can currently be used on Windows, macOS and Linux x64 to create standalone graphical applications.

That phrase, standalone graphical applications, is the thing to notice. This is not a web graphics library, and it is not a game engine. It is a set of tools for writing programs whose output is a picture that moves, and the applications it produces are desktop programs rather than pages.

The stack is Kotlin on the JVM, with a Kotlin and JS route that renders through WebGL, and the two are split into separate modules in the same repository. The two targets exist because the same sketch should be able to run as a desktop program and in a browser, and because the community that writes these programs is split between people who want a native window and people who want to share a link.

The readme points to a separate guide for the basics and the use of the library, and the project has its own website for news, showcases and events. The topics list says creative coding, graphics, JVM, Kotlin, shaders and WebGL, which is a good summary of the ambitions.

Nineteen modules, and the choice is the design

The repository structure table is the most useful document in the readme, because it says what the library is made of and, more importantly, what it is not.

The animatable module is tooling for interactive animations. The application module holds the application and program classes, which is the part that owns the window and the loop. The draw module is the drawing primitives, the shape module is classes and functions for working with two-dimensional shapes, and the color module is colour spaces. The event module is the event classes, the filter module is the built-in filters, and the extensions module is the built-in extensions to the library itself.

Then there are the format and utility modules. A DirectDraw Surface loader for textures in that format, an SVG module for loading and saving, a math module, a utilities module, and a binpacking module for the algorithm used for texture atlases.

Two of them are unusual and worth a second look. The null back end is a mock graphics implementation, which means you can write a sketch, run it in a test, and check the calls it makes without opening a window at all. That is what makes the library testable, and it is a design decision that pays for itself in any project that grows past a handful of sketches. The demos module is a collection of small demos that live in the repository itself, so the examples are compiled with the code rather than living in a separate site.

The repository carries more directories than the table lists, which reflects the build reality. There is a core module, a platform module, a module catalog, a dependency catalog, a common demo module, a WebGL common module, a web demo module, and modules with names that suggest specialised work, a font library and a tessellation library. The separation of platform-specific code into its own module is what lets the same sketch source target the JVM and the browser.

Building and installing it as artifacts

The build instructions are two sentences long, which is a good sign for a project of this size.

After cloning the repository, make sure you have Java 11 or newer installed and run:

./gradlew build

The readme warns that the build will take some time to complete, which is what you would expect from a project that compiles a graphics stack for two targets. It also makes a point about dependencies that is worth repeating: OPENRNDR does not depend on anything that is not on Maven Central, and builds should be easy and predictable.

That constraint has real value for a library that other people depend on. A creative coding library that pulled in a native toolchain or an artefact from a private repository would be a nightmare to build in continuous integration, and the readme is making a promise that a contributor can check.

To use the build from your own applications, the artifacts have to be installed into the local Maven repository, and the command for that is:

./gradlew publishToMavenLocal snapshot

The snapshot suffix is what marks it as a non-release publication, and the readme points to the wiki for a more detailed walk-through of building, publishing to the local repository and contributing.

For starting a project, the advice is to use the project template, which provides a quick start, and there is a separate template for the JavaScript and WebGL route, which the readme recommends only if you want to try it.

The web route is experimental, and the readme says so

There is one sentence in the readme that deserves more attention than its length.

The JavaScript and WebGL support is still experimental and under development, and the readme says that if you feel like trying it you should use the JavaScript template.

That is a plain statement of where the project stands, and it is the kind of sentence that saves people a week. The existence of a WebGL module and a web demo module in the repository might otherwise suggest that the browser target is a first-class one, and the readme is telling you it is not.

The structure of the code explains why the split exists rather than why it is incomplete. The JVM and the JavaScript modules are separate directories, and the platform and common modules sit between them, so the same sketch logic is written once and the graphics calls are bound to whichever back end is in play. The null back end sits at the other end of that spectrum, and the existence of both suggests the authors are serious about keeping the graphics layer abstract.

So the practical reading is this. The JVM route is the supported one, the Windows, macOS and Linux desktops are where the library is meant to be used, and the browser route is something to experiment with.

For an evaluator, the useful question is whether the abstractions hold up under a real project, and the template repositories are the fastest way to find out, since they are set up to be the first thing a new user builds on.

The project state, the licence and the community

The administrative details are short, and two of them need a note.

The first is the licence. The repository listing records a custom licence that the platform cannot classify, and the readme does not state one, so if you are considering commercial use you need to read the licence file in the root rather than assuming a permissive default.

The second is the release history. Version 0.4.3 came out in June 2023, 0.4.5 in September 2025 and 0.5.0 in September 2026, with the last push on 2026-10-11 and the repository not archived. So the project is being worked on, the versions are on a 0.x line, and the gaps between releases are long enough that the version you use will be old by the time you read this.

The build tooling is modern. There is a settings script in the Kotlin DSL, a build logic directory with the convention plugins, a dependency catalog rather than version numbers scattered through the build files, a module catalog, a Gradle properties file, and a Dokka directory for the API documentation. A dependency catalog in a multi-module project like this one is what keeps the versions of the shared libraries in one place, and it is the kind of tidiness that a project with seventeen modules needs in order to stay buildable.

The community channels are three and they cover different purposes. The website carries the news, the showcases and the events. A Discourse forum is for questions, tutorials and showcases. And a Slack workspace is for more direct contact.

The showcases are worth a look before you commit, because they show what people have actually built, and a creative coding library is only as good as the range of things people have made with it.

Editorial conclusion

OPENRNDR suits a programmer who wants to draw things and wants to stay on the JVM, especially if the output is a standalone application rather than a web page, since the JavaScript and WebGL route is explicitly experimental. It is a poor fit if you need a stable, long-supported API today, because the project is on a 0.x line with a year between some of its releases, and it is a poor fit if your graphics need are modest, since the toolchain is a Gradle build of seventeen modules. Before you start, look at the module table and pick the two or three you actually need, and remember that the null back end lets you develop the logic of a sketch before you have a window to draw it in.

Frequently asked questions

Official sources

1. Issues
2. openrndr/openrndr on GitHub
3. Project website
4. README
5. Releases