What I was thinking was moving this method to a subset of the PImage
class and effectively inlining the getter/setters and looking for
optimisations in the inlined code.

You also might big around in their library to see if you can get the
same effect combining some of their other methods.   Chances are that
will be faster than element by element processing.

Flatman wrote On 09/20/05 05:46,:

   That wasn't the point I was trying to make.  For
reference, here's your original loop:

   Now: If clone.height is the total number of rows in
your image, observe that the bottommost row never gets
processed; the loop stops after processing the next-to-
last row.  The point of imagining a one-row image is to
make this fact stand out: If clone.height is 1 the loop
begins by testing whether 0 < 1-1, and since this test
yields false, the loop never executes.  Is it really your
intention to leave the last row un-reflected, or have you
fallen victim to an off-by-one error?

   Similarly with the inner loop.  If clone.width is the
number of pixels in each row, then imagine what happens with
a two-column row: the loop tests whether 0 < 2/2-1, the test
fails, and the loop doesn't execute.  The point is not that
you really intend to process images of just two columns, but
that the misbehavior on a two-column image shows that the loop
is set up incorrectly and will also misbehave on images of
realistic width.

   All this is, of course, based on the supposition that
clone.width and clone.height are the dimensions of the
image you're trying to reflect.  The arithmetic in the two
clone.set() calls suggests that's the case, but it isn't
absolutely certain: maybe you've got an extra "guard" row
or column that resides in clone but isn't considered part
of the image, or is to be left alone for some reason.  It
doesn't seem likely, but it's possible -- which is why I
said that your loops "may be" wrong, not that they "are"
wrong.  You decide.