This is one of 3 follow-ups to my latest post, and is all about rendering. I will talk about the other 2 subjects in upcoming posts!
One fundamental problem with any fractal flame algorithm is that it just takes way too long to render an animation. Close to identical parameters are rendered with only slight changes between frames. This method evidently creates a lot of overlap, so your CPU is forced to compute the same pixels over and over again. What fr0st will try to accomplish is to retain some information from frame to frame during an animation render and save on recalculation times, which would significantly speed up rendering. A similar principle is already used in the current prototype of the fr0st renderer, where every pixel drawn slowly fades away, mixing into subsequent frames.
A simple analogy would be video compression. If you ever tried just stringing together a large number of individually compressed frames without using any codec, you’ll know that this will create a huge file size for your video. Most video codecs combat this by finding overlapping areas along the third dimension of the image, which is time. Any area of the animation that doesn’t change from frame to frame can be compressed considerably, as the same data from one frame in that part of the image could be applied to tens or hundreds of subsequent frames. This is of course a gross simplification of how video encoding works (an area in which I am hardly an expert). Even though these methods can cause a significant amount of quality loss, they’re much better than the alternative: being unable to distribute videos over the internet at all.
For me, this is by far the most important of the 3 areas I am currently working on. Fr0st is not meant to be a copy of Apophysis or Flam3; if I wasn’t trying to fundamentally change the way IFS rendering works, I wouldn’t bother writing an entirely new program. There are just too many good alternatives already out there.
In the 0.4 release the flam3 renderer will be included (through pyflam3), but the long term goal is quite different and will possibly be implemented using the lower levels functions of the flam3 library.
For now I can’t really say much more, because I haven’t quite figured it out yet. Only time will tell.