In principle, we only need to add #![windows_subsystem = "windows"] to the crate root to make it not spawn a terminal. But this would also make it not attach to the terminal it is called from, which makes the CLI more clumsy.

Ideally, we should also distribute a .cmd shim that calls the main binary and attaches it to its terminal. There are a couple of ways of doing this (I only remember the one used in mpv, right now), and I need to find out which one is better/easier to implement.

The default themes for attractor-egui are stored in default.json, while the ones in the Android app are stored in the Kotlin source code.

It would be easier to maintain if the themes were stored in a single place. This could be done by shipping default.json with the Android app and making the Kotlin code read from it, or by creating a code generator that generates the themes in Kotlin from the JSON file.

Would be cool to make the gradient accept luminance values beyond the ones allowed by the sRGB color space (I am already using the OkLab color space), and render the attractor with HDR colors.

I am mainly thinking about adding effects like bloom to the final image, but I think this could also allow creating HDR wallpapers for HDR displays.

I don't have a macOS to test this on, so I cannot ensure that this is working there. But as far as I know, All crates used support macOS.

The multi-sampling option works by multiplying each dimension of the attractor's aggregation buffer, and then downsampling it using a Lanczos kernel in the shader. It also applies the colormap to each pixel right before scalar-multiplying with the kernel, so each pixel is unnecessarily colormapped multiple times.

The problem is that the kernel grows quadratically with the multi-sampling order, making the rendering too slow to run in full real-time for a non-small multisampling value. But the kernel used is actually separable, so we can make the slowdown grow linearly by separating the downsampling into horizontal and vertical passes.

This was not first done, not only because it was easier to implement, but also because I was afraid of using really big intermediate textures (the current approach only uses a single texture for the output, and a u32 array for the input aggregate buffer). But this choice doesn't work well enough, so better to risk the alternative approach. The "too big textures" problem can at least be solved by splitting the rendering into tiles.

It seems like it's not doing great with my Macbook Pro's high dpi display. Looks to be half-sized, and the Configuration controls appear to be relative to the window (vs. the actual mouse position).

Originally posted by @jacobbarssbailey in #2 (comment)

Dithering is used to avoid banding artifacts in the smooth color gradient of the background. The current implementation of dithering were copied from Bevy's implementation. Not sure if I implemented it wrong, but it causes stripes for some color shadings.

It may be better change the dithering implementation. I have some done some tests in notebooks/dither.html.

The current implementation is in the shader script, more specifically here.