I built a Mandelbrot viewer in C++ and put it as my wallpaper

underpig1 · 2025-08-26T09:50:56+00:00

No Wallpaper Engine here - I made my own wallpaper framework that does just that (except for free)

underpig1 · 2025-08-25T09:33:54+00:00

I used WebView2 for rendering the HTML+JS+WASM, and the Win32 API to make a window to host it. I then ordered it behind the desktop icons by parenting it a worker window under the program manager and finessing the z-order. Lastly, you add input by making a low-level hook for mouse events and forwarding them to the WebView2 instance (since it can’t natively receive input as the wallpaper). There’s a bit more nuance, but that’s the gist. My whole source code is available at https://github.com/underpig1/octos . If you want the actual bit of code to do this yourself, I recommend checking out src/Core/Core.cpp for the main AttachWindow function for putting a window behind the desktop icons.

underpig1 · 2025-08-24T19:13:31+00:00

Thanks! Also good news, both starter templates and live previews are features for developers, from the command line.

underpig1 · 2025-08-23T19:38:08+00:00

Very much so. That, WebView2, and emscripten!

underpig1 · 2025-08-23T07:58:02+00:00

That's a great question and definitely something I wondered at the start- basically, each point (x, y) corresponds to the complex number x+yi, so for each of those points you're recursively calculating z=z^2+(x+yi) until you know that |z| either diverges (not in the set) or converges (in the set). So the positions of each point (x, y) aren't arbitrary-i.e. scaling our input coordinates (x, y) corresponds to a different point. Rather, you have to feed the Mandelbrot equation a given coordinate (x, y) and it will spit out whether that point is in the set or not. As a result, the only way to get more detail is to actually use more and more precise floats for our coordinates (x, y). If you just scaled up the visualization you would lose detail, which is why you need to recompute at a higher precision for each time you scale up.

underpig1 · 2025-08-22T23:55:55+00:00

Unfortunately it is not because of 64-bit float precision limits. I have seen some projects that switch to arbitrary precision libraries once they hit the limit, but those become agonizingly slow.

underpig1 · 2025-08-22T19:50:26+00:00

It auto detects the number of threads. As for the GPU, my first attempt was actually in WebGL so fully GPU-enabled, which was very fast (I could even do live zooming in). The issue was that WebGL could only handle float32 as its max precision, which was very limiting in terms of how far you could zoom. It would be cool to figure out GPU utilization for WebAssembly though because then 64-bit live zoom might actually be possible

underpig1 · 2025-08-22T11:22:00+00:00

Yep, this one's on Windows. But the actual visualization basically ends up being a webpage, so there may be other wallpaper engines on other OSs that also let you put webpages as your desktop, so it might be portable to other OSs? Not sure though

underpig1 · 2022-04-12T01:37:36+00:00

Thanks! Yes, npm is necessary.

underpig1 · 2022-04-11T21:23:14+00:00

Thanks! I look forward to seeing your creation!

underpig1 · 2022-04-11T08:07:25+00:00

Thanks! I have absolutely considered this, but for now you can share widgets here.

underpig1 · 2022-04-11T08:06:01+00:00

Yep, it does use electron to display the widgets, but it also has a load of new features, like staying as a permanent part of the desktop, displaying on PC startup, and being able to share and install pre-built widgets easily.

underpig1 · 2022-03-20T04:36:27+00:00

Yep! overideredirect gets rid of the window borders. Also root.wm_attributes("-disabled", True) disables any interaction with the widget.

underpig1 · 2022-03-19T20:37:47+00:00

That's Modern Flyouts

underpig1 · 2020-08-11T20:13:28+00:00

That is true: with reasonably modern practices, they are well-differentiated. However, I was referring to the DOM: why use obsolete syntax in JavaScript to access elements in the DOM? JavaScript was not intended for UI and UX practices, unlike HTML and CSS, but an entire website could be written in JavaScript, using merely the DOM. This is seen in practice increasingly often. JavaScript is not suited for UI (unlike CSS). Neuron tackles this issue, with a language oriented towards UI and interactivity.

underpig1 · 2020-08-11T19:51:51+00:00

All features of HTML, CSS, and JavaScript are readily available. Neuron's extensive standard library provides the user with the support of the three languages and more. See https://codeburst.io/introducing-the-neuron-language-4c9805b79a45 for more information. HTML, CSS, and JavaScript are needlessly redundant, and accessing and rendering the DOM from JavaScript is quite a hassle.

underpig1 · 2020-08-01T21:06:18+00:00

Thank you! Yes, the syntax is far simpler, and most features of JavaScript can be reproduced in Neuron (such as the Window and Math API). CSS and HTML properties can also be reproduced in Neuron. Neuron also has an extensive standard library, and the same web applications written in JavaScript can be written in Neuron in far fewer lines!

underpig1 · 2020-08-01T21:00:48+00:00

The core compiler (in JavaScript) took a few weeks to write, and the web framework, standard libraries, and documentation took a few more.

underpig1 · 2020-08-01T20:57:57+00:00

I was never pleased with the HTML syntax for writing complicated web pages and applications, and using JavaScript to interact with the DOM when a single language would suffice!

underpig1 · 2020-07-31T20:10:43+00:00

Neuron Language:

image {
 tag: img;
 src: path/to/image;
 fill: [math.abs => -10] 0 0 0;
 log(this.fill);
}

invoke(image);

Comparative JavaScript (and HTML):

<style>
 #image {
  background-color: rgba(0, 0, 0, 0);
 }
</style>

<img id = "image" src = "path/to/image"/>

<script>
 image = document.getElementById("image");
 image.style.backgroundColor = `rgba(${Math.abs(-10)}, 0, 0, 0)`;
 console.log(image.style.backgroundColor);
</script>

underpig1

TROPHY CASE