David,
Hmm. Fractint would stop calculating image when it's done, right? So
waiting until the image is done at the default setting (640x480, which is almost instantaneous on my laptop) means Fractint shouldn't be drawing anything anywhere.
Can it be set to use a buffer instead of a "screen" surface? Or is that just the same thing?
There is a buffer for the raw pixel data. This gets put into a texture buffer, which then gets copied into a rendering buffer, which then gets presented (blitted) to the screen/window. During the calculation of an image, there is a small delay during which the raw pixel data gets updated, then the rest of the buffers get updated. This speeds up image calculation by writing multiple pixels to the screen instead of one at a time. The need for using a texture and a rendering buffer has to do with how/when pixel formats get translated in SDL.
Apparently on my system, XFractint's not reliably able to save an image that it can reload.
Try reducing the absolute path to the executable. Might not help.
My initial thought with the 4K and FHD images were running out of memory... but that shouldn't apply to the default 640x480 video mode. Previous versions handled 25kx25h fractals before, so that mere 4K shouldn't be a memory problem, right?
No, there shouldn't be a memory problem. At least not having to do with the image size. There is probably a memory space that gets overrun. This usually happens with text buffers. I did just run into a problem with the windows version not being able to restore images. I get an error because the line "assert(r < TEXT_HEIGHT)" fails. Could be you are seeing this without getting the error message.
I have the next five days off, I'll see about doing that. Is there a debug mode that might help figure things out?
No, there isn't really a debug mode. I use the Code::Blocks IDE, which lets me debug. There are some debugflags that turn off/on certain Fractint features, but for the problems we are seeing, they won't help. Jonathan