In the next release of fr0st, it will use 64-bit buffers when rendering previews and thumbnails. This has increased rendering speed by about 10%.
Where does this speedup come from? It’s pretty simple: All math for the iterations is done in 64-bit no matter what. Therefore, when using a 32-bit buffer, flam3 has to cast from double to float and check for overflow at each iteration. In layman’s terms, you always calculate the fractal very precisely, but if you use a smaller buffer, you need to ’round’ the numbers to fit them into the available space, which makes the rendering process slower and less accurate.
There are some boundary conditions in which the compounded rounding error caused by using the smaller buffer creates a slight shift in color when changing opacity. This can be very visible when creating animations.
The downside is of course double memory usage. But I still recommend to use a 64-bit buffer for rendering whenever possible. It’s worth sacrificing a bit of oversample to do so (as long as you never reduce it below 2!). If you’re rendering huge images where memory is at a premium, you might be forced to reduce the buffer to 32-bit, but I would only do that if the alternative was rendering in slices.
The Fr0st Blog 
Thanks for all the great work on Fr0st absolutly love it! I am confused a bit though, what is so bad about rendering to slices?
Well, a fractal flame is an iterated function system. That means no matter how small the part of an image you’re rendering, you have to calculate all the points anyway, even if they’re off-screen. So when you render in slices, you have to recalculate the entire image once for each slice, so you lose a lot of rendering time. Therefore, it’s worth lowering your oversample or buffer size if it will make the whole render fit in memory.
Ok so there is just a loss in rendering time but no quality loss or anything like that. Sweet thanks man!