jset-desk

Rust crate jset_desk

An application for drawing "trippy fractals" by iterating a function and coloring pixels based on how long the associated complex numbers take to diverge.

This is a more powerful, desktop version of my jset-wasm project, which you can find in action here.

Installation

You can download a Windows 10 binary of the (almost always) most up-to-date version.

Otherwise, you can compile it yourself. There aren't many Rust crate dependencies, but FLTK is a doozy; you'll need to install all of the dependencies of fltk-rs, but then it should just work. Remember to build a --release version, or it'll be disappointingly slow.

Use

Clicking the mouse on the image will cause the image to be recentered at that point.

Changes to the color map, the iteration parameters, or the image size will not be reflected until you focus the main window and hit return (or click to recenter).

If you save your image with the view of it scaled to anything other than 1:1, it will save at that scale. This is fine if you want to smooth out the image by making it huge and scaling it down (although just about any image editor will have a better scaling algorithm), but if you want to save it at 1:1, make sure you click on 1:1 before you hit save.

You can also save your image parameters: iterator, coefficients, color, etc., and then load them later to continue work where you left off. I made the load button smaller so you'll be less likely to hit it and wipe out any work you're in the middle of accidentally.

As of 0.2.5, all images are automatically saved with the image parameters embedded as metadata, and can be loaded just like .toml files.

As of 0.2.7, colors in the color map pane can be drag'n'dropped onto each other. So, for example, if you have just set the end color of the final gradient in the pane and want the "default color" to be that same color, just click on the final color button, drag the mouse onto the default color button, and release.

Roadmap

In no particular order, I'd like to add:

• saving natively in .png format. It's more complicated than just adding crate png as a dependency and calling a function, which I guess shouldn't be surprising. Done in 0.2.3, but there are a bunch of PNG parameters, so expect tweaks in the future.

• keyboard shortcuts to change pane focus. FLTK inputs really like to eat key events. There has to be a way to do this, I just haven't figured out how because the fltk-rs documentation seems to assume you're already intimately familiar with using the C++ library. As of 0.2.2,

  • alt-A will raise the iteration window
  • alt-z will raise the color window
  • Return will, if it's not raised, raise the main image window; if it is raised, it will redraw the image. So when you make a change to the color map or the iteration parameters, you can just hit return twice to redraw the picture.

  This isn't my first choice for how to do this, but it's something that works and is moderately more convenient than having to click to focus all the time. I may return to this in the future.

• saving the image, color, and iteration parameters to a file, (and subsequently loading them) so you can resume work on an image, or generate a super-high-rez version later if someone likes it. This should be easy, but it involves getting another heavyweight dependency (serde) involved. (I love serde, though, don't get me wrong; it's just a huge dependency.) Done in 0.2.1.

• SIMD. The iteration step is already parallelized, but I'd like to explore speeding it (and color map calculation) further with some vectorization. LLVM supposedly does some vector optimization when it realizes it can, but I don't know how smart or aggressive or effective it is. This is going to take some experimentation and profiling. UPDATE: I tried writing an explicitly-vectorized complex number implementation, and a typical Mandlebrot-style iteration with it actually took three times as long as the naive implementation just using regular multiplication and addition. Clearly, the LLVM backend is way smarter than I am, and it may not be worth barking up this particular tree.

• Once native .png saving is worked out, I'd like to explore saving the "image parameters" as an EXIF sidecar to the saved .png, so you'd never even have to worry about saving a separate file. You'd only have to worry about image manipulation programs stripping your EXIF data. As of 0.2.5, all PNGs are saved with embedded metadata, and can be reloaded and regenerated from the load dialog, just like explicit .toml metadata files.

Help

If you have any experience with creating FLTK UIs, I'd love to ask you some questions. If you've ever themed FLTK, just go ahead and make a pull request. I don't care that this looks like a Win95 app, but it'd probably be nice if it were slicker.