Welcome to Fractal Forums

I have noticed 2 ways in which Kalles Fraktaler can be found to be rendering much slower than it actually can. I don't know the causes and I don't know whether these are related.

The first is that something is taking up a lot of time when doing renders at a resolution close to the maximum. After the first reference point there are very long periods when the program uses the full capacity of one CPU core. Could it be the series approximation taking much longer with large images? I would guess it's not the reference calculation because that's multithreaded. I was also thinking of image resizing code. The zoom-in animation is slow on my computer when I use a resolution larger than the default 640×360. I can imagine, if similar code is used to display the render in progress, it taking a very long time at a resolution that is 2330 times larger than default.

The second problem happens at large depths (say, E3000+, but that's just a guess). It has happened a few times that the first rendered pixels started to appear and it was so slow I could see them appear in groups of maybe 12. After restarting the program the rendering is a lot faster. I couldn't get the rendering to be faster again without restarting the program. Thus far, each time it happened, it was after I did the following: I make use of Newton-Raphson zooming and I let it zoom to the minibrot. When the first reference is computed, I select "reuse reference" and set the zoom depth to what I want it to be manually. Then I can use the same reference to zoom in and out and find the morphing I want. Ideally it's at 0.75*(minibrot_depth) but sometimes it's not. Something that may be relevant is that I use hibernate. Especially at large depths, I may hibernate and restart my computer several times during the Newton-Raphson zooming.

i think kalle ties the number of series terms used to the resolution, increasing the terms with increased resolution.  i doubt there really is any good heuristic you could come up with to make that behavior optimal in all cases.  is that behavior able to be overridden / configured ?  i suspect overall it is a misguided approach

You're right. "Auto approximation terms" can be disabled and the number of terms can be set. I may have forgotten that when I attempted the large render.

Yes, first issue is that series approximation is using more terms for higher resolution.
I didn't limited it to a reasonable maximum though...

Second issue I don't know. I guess you've done like that many times without problem, or does it get slow every time you do like that?
I tried it but couldn't see any difference myself...

Effectively often kalles gets very slow in some spots. I found that it happens often when the images are closer to the bulb or in some elephant valley locations while the classic "antenna" is almost always super fast.

thats just the mandelbrot set  O0

It doesn't happen every time, just some of the time. Unfortunately I don't know how to reproduce the problem. Maybe it happens at shallow locations too but it's just not noticeable there. I will let you know if I find something.

:laugh: :nono:

Coming back to mention this wasn't it after all. It's also hard to say whether there's progress or not because the reference count is unreadable due to there being too much text in the field (probably because of the 4-digit exponent in the depth).

I'm currently doing a render. The first reference was computed and all the pixels were computed, some of them glitches. It's stuck somewhere between that and where it would start using the next reference to solve glitches. I just noticed the CPU usage drops to close to, but not quite, 0% (0,07-0,12% and I have 6 cores and 12 threads) when the program is minimized.

Oh, I think there is a problem with saving jpeg when the window is minimized, can it be that?
Someone wrote that to me long ago but I haven't remembered having a look at it...

That seems unlikely to me because I'm not trying to save a JPEG - it's a problem that affects the rendering - but who knows the problems may be related. I also tried Claude's build and it crashes at this stage. I didn't have enough RAM to keep both processes so I'm now trying it again with the normal kalles fraktaler 2.11.1.

I have attached the parameter file that I'm trying to make a render of. This is what I do:
1. Open kalles fraktaler;
2. Set the window to 1000×1000;
3. Open Iterations window and set Bailout=2, uncheck both "Approximation low tolerance" and "Auto approximation terms", set Approximation terms to 66, click OK;
4. Open Set image size window and set Width to 23160 (which automatically sets Height to 23160 as well);
5. Wait for the render to finish. I might minimize the window a few times.

Maybe I should upload a debug build without symbols having been stripped - it's much bigger but if you know how to use a debugger it could help find the problem?


I tried to reproduce, but ran into a separate (?) issue - WINE doesn't allow bitmaps more than 128MB (aargh!), which means the maximum size is around 7723x4344 (16:9) or 5792x5792 (1:1):

https://source.winehq.org/source/dlls/gdi32/bitmap.c#0197

Then KF doesn't check the return values of the bitmap creations, which eventually leads to memory corruption/crash if it fails:

https://code.mathr.co.uk/kalles-fraktaler-2/blob/refs/heads/master:/fraktal_sft/fraktal_sft.cpp#l8704


Another issue that might happen with huge images is a couple of cache-smashing loops, that will perform very badly (the 23160x23160 meant KF needed more RAM than I have, so it was thrashing the hard disk with swapping pages ot disk and back again, with low CPU usage):

https://code.mathr.co.uk/kalles-fraktaler-2/commitdiff/9deda85f56fb939b28d1485d5c4ae0d2cb8ce838

Bitmap size should not be the issue on windows I think. 23160×23160 is just below the maximum of 2^29 pixels (although I can't easily find a source that confirms this). It's a resolution that works in Mandel Machine at least. I have more than enough RAM. Cache - I don't know.

I'm currently rendering 4 tiles of 16000×16000 and that seems to work fine.

I haven't used one before.