Simple transform2() images

It extends the capabilities provided by the current transform() function by adding the ability to transform the colours of images and to take more than one image (or even zero images) as input. transform2() also seems to be faster than transform() (it's now only a little faster than transform() for the benchmark I'm using - I added some exception prevention code which may be slowing it down.)

I've created a web page demo.

I still need to do the following work on transform2():

• Imager-0.34pre3 includes transform2() (available from the development page)

• currently the startup time for parsing infix expressions is fairly long, since we need to compile the grammar the first time. It may be desirable to be able to save a parsed expression for later use. There isn't such a delay for postfix expressions (rpnexpr), so this isn't critical.
• provide some built-in transformations, like twist, ripple, tile
• improve the errors reported for infix parsing
• allow iterative expressions. This will require a lot of work:
  • implement jump on true, jump on false and unconditional jump instructions
  • modify the code generators so that variables survive through jumps (currently each assignment to a variable allocates a new register, this won't work in iteration.) More than likely a while loop would generate code like:
    put condition in ra
    jump_if_false ra,labelb
    labela:
    ... loop code ...
    put condition in rb
    jump_if_true rb,labela
    labelb:
    This would allow the optimizer to make the same assumptions it currently does (within basic blocks).

    After some thought, this isn't going to work properly. I'll need to write some proper code analysis.

  • modify the optimizer so that it understands jumps (including basic-blocks). This includes extra optimizations:
    • code hoisting (this is probably a different optimization to the one below)
• look for other optimizations, some possibilities: (The percentages are from hacked tests, it's possibly they could improve or worsen depending on the final implementation or the processor used.)
  • reduce the call overhead in calling to rm_run() - currently we supply a bunch of parameters. It might be faster to put these in a structure and pass a pointer to the structure.
  • inline rm_run() into i_transform2() (compiler inlining increased speed by 3.4%)
  • oops, we set x for each call to rm_run() - this probably won't make a noticable difference. (difference too small to accurately measure)
  • for bigger output images working by column could be causing caching or paging issues. (makes ~1% difference)
  • code hoisting - try to split up execution so that if part of the expression is invariant over a whole row, we only calculate it once per row. This wouldn't help the current benchmark expression.
  • reduction in strength - replace expensive operations with cheap ones (there's a technical name for this) - eg. replacing the /10.0 with *0.1 increases the speed by 12%.
  • inline call to im->i_f_gpix() (4.5%)
  • constant folding in the optimizer

• error reporting - now put the error into $Imager::ERRSTR

Image	Expression
	Base image
	x 25 % 15 * y 35 % 10 * getp1 !pat x y getp1 !pix @pix sat 0.7 gt @pat @pix ifp
	x 25 % 15 * y 35 % 10 * getp1 !pat y 360 / !rat x y getp1 1 @rat - pmult @pat @rat pmult padd
	x y getp1 !pix @pix value 0.96 gt @pix sat 0.1 lt and 128 128 255 rgb @pix ifp
	x 35 % 10 * y 45 % 8 * getp1 !pat x y getp1 !pix @pix sat 0.2 lt @pix value 0.9 gt and @pix @pat @pix value 2 / 0.5 + pmult ifp
	x y 160 180 distance !d y 180 - x 160 - atan2 !a @d 10 / @a + 3.1416 2 * % !a2 @a2 180 * 3.1416 / 1 @a2 sin 1 + 2 / hsv
	x y 160 180 distance !d y 180 - x 160 - atan2 !a @d 10 / @a + 3.1416 2 * % !a2 @a 180 * 3.1416 / 1 @a2 sin 1 + 2 / hsv