<p>Godelbrot, a Unix-Style Mandelbrot renderer, is nearing 0.0.1</p>
<p><a href="http://godelbrot.functorama.com" rel="nofollow">demo</a></p>
<p><a href="https://github.com/johnny-morrice/godelbrot" rel="nofollow">source</a></p>
<p>UI tested on iPad and modern desktop browsers. Frontend is GopherJS, rendering occurs on server side. Why? Read on.</p>
<p>My dream is to provide a flexible architecture so that people who want to experiment with drawing fractals (such as this effort <a href="https://github.com/esimov/gobrot" rel="nofollow">https://github.com/esimov/gobrot</a>) can plug their idea into Godelbrot, and see it on web, on desktop, on mobile, and further render to MPG.</p>
<p>In this work I have found a new appreciation of the work of the Processing folks, who are attacking a similar, but much broader problem.</p>
<p>The idea for 0.0.1 is to lay out a roadmap for its infrastructure. Most fractal fans want movie generation; user-defined algorithms; a test bed for fractal render algorithms. </p>
<p>In the backend we support movie generation already: Godelbrot is set of orthogonal apps so we get this for free. A stream of config files is piped into the render program, producing a stream of PNGs, which can be piped into libavtool...</p>
<p>These other issues shall be address by a plugin mechanism before 0.0.1. The current method of using facades and factories to cope with multiple fractal algorithms and numerical systems (e.g. math/big vs native). is ugly, over complicated, and ignores the benefits we have seen elsewhere through a multiprocess/stream based architecture.</p>
<p>Architecture is designed for ease of client implementation. I am wishing to implement OS apps outside browser, reusing client application workflow through communication via channels.</p>
