A deterministic Java 17 animated Julia-set renderer. Each frame walks c along the Mandelbrot coastline, lingering where the Julia set is most intricate. The seed kernel visits every pixel and iterates z = z^2 + c until escape, with no period checking, tiling, or parallelism. That leaves a clear optimization opportunity while the correctness tests protect the iteration counts.
Colour mapping is display-only. Discovery should maximize frames_per_second without changing those counts or weakening the tests.
- JDK 17 or newer
- A graphical display for the (default-on) visualization pass; see below for headless behavior
Compile:
./gradlew assembleTest:
./gradlew testBenchmark:
./gradlew run --args="--no-visualize"The benchmark measures 20 frames at 1280×960 after three warmup frames and writes frames_per_second to artemis_results.json. That figure is headless: no window, no colour mapping, no Swing. Artemis tracks this number, not the FPS shown in the visualization.
The measured benchmark is always followed by a visual pass of the same 1280×960 path, showing the Julia set on the left and the parameter plane with the path of c on the right. The window starts playing from the beginning of the path. The on-screen FPS includes display overhead (colour mapping and Swing) and is not the Artemis metric. Pause and the slider jump to any point on the path; each frame is computed from its index, so nothing has to be simulated in advance. The window stays open until you close it:
./gradlew runPass --no-visualize to skip it entirely, e.g. for a faster local loop or an Artemis runner:
./gradlew run --args="--no-visualize"The visualization is never part of the timed section, so it cannot affect frames_per_second. On a runner with no graphical display, the visualization pass prints a warning to stderr instead of failing the whole command. The measured artemis_results.json from the timed section is written first and is unaffected either way.
Licensed under the Apache License 2.0.