Since the configurator does not automatically find the number of bits we need, this field is unset unless you invoke configbrot with -prec

Omitting this parameter leads to a "divide by zero" crash when renderbrot is run.

I wrote my own big Float serialization method since math.big.Float.Text did not allow precision detection in go 1.5. This has been implemented in math.big.Float.Text in Go 1.6, so we can delete some source code.

Implement plugin for permutation based algorithm ala Superfractal thing

Command line zoom config tool.

Means, for a start, we can remove zoom arithmetic from webdelbrot's javascript.

Moving forward, clients won't have to do math.

The webservice described under johnny-morrice/webdelbrot#7 is to be moved to the godelbrot project.

This will enable other clients to have a ready made frontend service for rendering, zooming, controlling concurrency etc.

Refactor clientbrot into a portable restclient library.

It must be portable in that it compiles to a reusable static archive and gopherjs library. The properties it must obey:

• Delegates network call to clients (Hollywood principle)
• Does not use OS-specific features

I don't know why but

godelbrot --palette pretty --width 1920 --height 1078 > error.png

Will produce a glitched image. Other resolutions seem okay.

restclient 'Cycle' method should return render status or it's impossible for a client to autonomously conduct a zoom

The restclient lib should communicate its needs to GET and POST with loose coupling.

This is because certain types of clients may need to handle their requests in a manner that cannot be accomplished with a single method call. E.g. a javascript wrapper should use the standard ajax methods, which are async and have their own callbacks.

I feel like this should be done with channels, for input and output. These receive and send simple data-only structs. E.g.

Output:

{
"method": "POST",
"url": "blah",
"content-type": "application/json",
"data": "blahblahblah"
}

Input:

{
"output": as per above,
"error": null,
"http-response": {
"status": 200
}
}

As a middleware, restfulbrot is sometimes invoked on a different port than the port used by its frontend.

Therefore it should support CORS, with a basic command line flag to set permitted origins.

Most of these packages are split up to enable ease of development. They aren't intended for end-users. As such, they should be in an "internal" folder.

Command line app to automatically create zoom movies. References to Movie Maker are per #4

Automovie

Takes input:

• Godelconfig

Sends output:
(none)

Side effects:

• As per Movie Maker

Operation:

• Loop Autozoom
• Send Autozoom output to Movie Maker

Autozoom

Takes input:

• Godelconfig
• Fractal .PNG

Sends output:

• Zoomed godelconfig

Side effects:
(none)

Operation:

• Find interesting area in the Fractal
• Update godelconfig with found area

Remove libgodelbrot directory and put that stuff in the root.

Move the godelbrot binary to a new 'godelbrot' package.

As work on the nascent middleware REST service (check the webservice branch) continues, it would be very handy to adopt levelled logging across the infrastructure.

Backend zoom is just off.

While we are deliberately using a multi-process, multi-binary architecture as part of a study into UNIX-styling programming, there is no need to inconvenience our users by having them learn all these commands. So we should develop a simple wrapper using the Cobra that provides a familiar CLI usage.

Three commands to install? That's silly.

Configbrot should automatically select the appropriate precision for a given zoom.

This should respect autodetection of numeric system.

It occurs that subdividing the plane is fraught, and we should instead subdivide integers i.e. image region

Do this after plugins are implemented, for quicker turnaround.

The frontend should support movie zoomage as the backend does.

This will also require new features in the REST service.

When running out of precision, it occurs that one could garner more precision by a render to a larger output image and then downsample to the correct size.

This is relatively easy e.g. compared to permutations.

Arbitrary precision render is so slow that it is unusable in anything but the smallest bit-precision.

Look into dividing the bit-precision by a constant "fudge" factor.

Profile the big sequence algorithm and find out why it is so slow.

If after eliminating garbage and other clumsiness, it is still too slow, we can look into doing the Mandelbrot Escape algorithm with bit-level composition of operations over an array.

There is an intermittent zoom defect. The problem has been tracked down to a memory aliasing issue in our arbitrary precision plane projections.

All public functions, methods, and types need documented.

Pre 0.0.1, a lot of things are changing internally but the main library should not expose too much.

Annoying little issue with extra slashes being added dumbly to URLs somewhere.

We should see a deformed bulb with no-fixing in place

Easy feature and big boon.

All we need for this is to support a list of RGB values in the config file. Producing such a list is the hard part.

Note I am not planning GUI support for 0.0.1.

json config files currently use numeric identifiers when we are referring to const enums in libgodelbrot.

We should instead use strings that describe what we expect.

Since there is a new config packag, this can be done in an obvious place without any real changes to the backend proper.

We should define or use an existing formula specification language in order to interpret and compile user formula for fractals.

Targets (not expecting to get all of these done in the first implementation):

• Bytecode for interpreter
• Native CPU via LLVM
• GPU via CUDA or OpenCL

Must integrate with plugins and clustering.

Note that plugins allow users to write highly optimised algorithms, so it's not vital that formulae be optimised or transformed in any way. A straightforward pixel by pixel iteration would be easier for users to understand too.

I am planning a graphical (desktop) client to enable movie generation for the next release. It will consist of several tiny apps that communicate through pipes. It will begin life in a new package, but I have to document this somewhere.

Viewer

Takes input:

• Stream of Godelconfig
• Stream of fractal .PNG (greyscale)

Sends output:

• Stream of selection state (highlighted area for zoom)

Side effects:

• GUI manipulation

Operation:

• Colours greyscale fractal and puts it on screen.
• Mouse is used to highlight new zoom regions.

Zoomer

Takes input:

• Stream of selection state

Sends output:

• Stream of Godelconfig
• Stream of fractal .PNG (greyscale)

Side effects:
(None)

Operation:

• Renders each frame.

Saver

Takes input:

• Stream of Godelconfig
• Stream of fractal .PNG (greyscale)

Sends output:

• Stream of Godelconfig
• Stream of fractal .PNG (greyscale)

Side effects:

• GUI manipulation

Operation:

• Allows user to save current frame into movie.

Movie Maker

Takes input:

• Stream of Godelconfig
• Stream of fractal .PNG (greyscale)

Sends output:
(None)

Side effects

• Writes Godelconfig files
• Writes fractal .PNG files (greyscale)

Operation

• Interpolates between user selected frames
• Saves interpolated frames to disk.

Just pass a RenderRequest to those methods that need it.

For really fast renders, we should run on a computer cluster.

This is pretty easy. Restfulbrot, when rendering a movie, could pass work onto other machines.

This does call for a new program clusterbrot, to instantiate machines on cloud architecture.

While godelbrot is flexible in terms of its internal engineering, for true flexibility fractal render algorithms ought to be external code that implement a plugin interface.

A likely plugin provider is

https://github.com/hashicorp/go-plugin

We assume in any case where the user is getting bored, the complexity of rendering a fractal dwarfs the time to copy output over the loopback interface. :)

Automatic zooming into interesting areas. Backend already supports zoom movies (pre 0.0.1).

Getting visual defects with bigfloat+region. Looks like it takes place below the Y axis, but I haven't really investigated.

I tracked a similar problem with bigfloat+sequence down to unintended reuse of a math.big.Float object.

I can see a number of places where we don't explicitly Copy(). I didn't think it would be a problem, since they weren't used past that point (in terms of writing to the receiver). Perhaps it would be best to Copy() every time (premature optimization being the root of all evil and all).