Hi lycium, thanks for giving it a look.
I believe you are the author of Chaotica, correct?
I have indeed tried Chaotica during the course of evaluating what's out there. I do like the interface, but never fully understood exactly how to use it. I was also unclear on whether it uses the GPU for iteration or not. I always wanted to learn more about it, but didn't have the time because I was so busy working on Fractorium. Do you have a link to any good write-ups? I know it's closed source, so I understand you probably won't give up the secret sauce. But any information is always welcome. I find that I can usually understand something better if I first get into the same frame of mind as the person who created it.
As far as speed, you are correct that the performance of the CPU renderers of both of our projects are probably roughly the same. Although I'm not entirely sure what the progress bar in Chaotica is telling me. I would love to know more so I can better gauge performance. One thing I did notice is that Chaotica maxes out all CPU cores. Is it doing that *with* locking? If so, kudos on the algorithm improvement because flam3 basically drops down to single core performance when locking.
Give the GPU a try on Fractorium, it gives real-time interactive feedback that is the fastest I've seen.
As far as thread locking goes, yes that is the killer problem with multi-threaded IFS in general. I've spent time thinking about it and researching it and came up with this:
CPU:
-By default, the threads are not locked when writing to the histogram in both the interactive editor, and during final render.
-If you run the command line executables, there is an option called --lock_accum which does locking. It's false by default, but setting it to true will give full accumulation locking compatibility with flam3. The problem is that it will drop performance down to that of a single thread, because all threads must wait while one accumulates.
GPU:
-Thread locking is unsupported. Doing so on a GPU pretty much brings it to its knees and defeats the purpose. If you read through the cuburn paper, you'll see that they tried every approach imaginable.
After looking through all of that, I thought to myself "why am I doing this". When inspecting the output images, I didn't see any difference between locking and not locking. It seemed like something that was attempting theoretical purity, for purity's sake. So I decided to omit it. If someone has a demo comparison of images that were rendered using locking vs. not locking, and it has noticeable artifacts, I might look into it some more.
I've thought of a few possible options for locking on the CPU side that don't kill performance so badly, and was planning to look into them more in the future. For now, I just wanted to get this first version out.
When I said full compatibility with flam3, I was focusing more on implementing all of the features, such as interpolation, temporal samples, density filtering, supersampling, spatial filtering and coloring as well as advanced features like early clipping and highlight power. That's what I meant, but technically you are right. Perhaps I'll reword that part of the wiki to be more clear.
Don't worry about nitpicking, I welcome input. That's why I posted it here. I really hope to get more input and involvement from other developers. We'll see how it goes.