On Friday 05 March 2004 3:46 pm, Hiram Berry wrote:
Somewhere in the fractint documentation I came across explanation to the effect that calculations done in fractint fell into one of three categories, once per image, once per pixel, and every iteration. I assume an example of the first is assignment of p# values on the z-screen, stuff before the ':' encompasses the second, and stuff after the ':' is the third category. But what about expressions that will be constant over an entire image, but need to be specified in the body of the formula before the ':' ? Is there a way to explicitly tell the parser to do that so that it doesn't redo the unnecessary calculations every pixel? I think it is too much to ask to expect the parser to make this optimization implicitly, and my benchmarking indicates that such optimization is not done.
The parser does not make this optimization. The formula is read in and put into one executable string of op codes and then called as the once per pixel routine for the formula type. Currently there is no way to split out part of the formula and only execute it once per image.
I raise the question of syntactic orthodoxy only because I did find a hack, which follows, that seems to accomplish it. It really doesn't feel right though. The hack is to put the once per image initialization code inside an IF..ENDIF block that (hopefully) executes only on the first pixel of the image. It worked when I applied the technique to "SliceJulibrot2.frm", speeding up the rendering of an "easy" image severalfold. However, the code just doesn't feel right. It relies on an assumption that the drawing technique will render pixel (0,0) first, which I tried to ensure by setting the PASSES=1 option, but I really don't think that can be assumed. So I really hope someone will tell us the orthodox way to accomplish once per image initialization.
Your optimization should work with most passes types except possibly diffusion. The major problem is that if you save a partially completed image, it will not resume correctly because then the first pixel calculated will no longer be (0,0). Certain key strokes may have the same effect if the formula gets read into memory again (like <z> followed by <esc>). Jonathan