Bernd,
Actually in my testing on my machines, over about 20 tests, your change ends
up being slightly slower by about 1%, depending on the images :) I think
it's because you downshift into checking pixel-by-pixel again, and there
would have to be fewer checks that way then if the check range were larger.
It's interesting how the timed duration can change from one execution to the
next.
[I] added a forward search when the
comparison is not unequal, figuring that going forward yields faster
results. Well it kind of does, if one thinks 5 to 10 milliseconds are an
improvement...
put 4 into tIncrement
[...]
-- we found one or more unchanged pixels; skip this section of data
add rangeToCheck to currPixel
-- this is added to Bill's original code
-- assume there are more unchanged pixels and go forwards
repeat while char currPixel+1 to currPixel+tIncrement of ImageA = \
char currPixel+1 to currPixel+tIncrement of ImageB
add tIncrement to currPixel
add tIncrement to tIncrement
if tIncrement > dataLength then exit repeat
end repeat
-- end addition to Bill's code
-- and update the range to encompass the remainder of the image
put dataLength - currPixel into rangeToCheck
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
