Test stack "speed of imagedata processing and paintcompression"

[Wilhelm Sanke]

I have submitted a bug report to the "Revolution Quality Control Center" 
(what a modern neoliberal term) to which number 5113 was assigned.

I post the report to this list, too, because those Metacard users that 
intend to make a transition to the Revolution IDE may run into 
unexpected difficulties when they deal with imagedata processing in 
their stacks.

The default setting for the paintcompression in all engines is RLE. The 
Revolution IDE changes that setting to PNG, which is then transferred 
even  into Rev standalones via an encorporated script.
Rev users would be well advised to set the paintcompression to RLE (or 
at least to JPEG, which is only slightly slower) in their openstack 
handlers.

Here is the text of my report:

"There is a test stack with test and result pages that demonstrate the 
reported effects (you need of course to launch the stack with the 
different engines).

 <http://www.sanke.org/Software/TestStackPaintcompression.zip>

Because of the included test images and a possible "full-screen" view 
the stack has a zipped size of 14 MB. I stripped my emerging Photo Tool 
down to four filters and three images, the first with 5 different sizes, 
the other two with a size of 2048x1536.
 Derek Bump's "convolve.dll" is included.

 Apart from the individual structure of the respective script, the speed 
of imagedata processing depends on two additional factors:
- to some extent on the engine version (and IDE),
- as a more important factor on the paintcompression.

The fastest engine is version 2.6.1 (Metacard 2.6.6). The speed 
difference to engine version 2.8.1 - while using the same 
paintcompression - can reach 33% (compare the results for the 
"scripted-matrix-version filter").

Concerning the factor paintcompression, the most extreme results of the 
tests demonstrate that using PNG paintcompression can be up to *twelve 
times* slower than wih RLE.
The speed difference extends to 400% when looking at the results for 
applying the DLL, PNG paintcompression is here four times slower than 
RLE, JPEG is somewhat slower than RLE.
One test concerned the retrieval of image contents - size 2046x1536 - 
from imagedata and compressed imagedata stored in custom properties. 
With the paintcompression set to PNG, image retrieval is up to twelve 
times slower than with RLE. In this case, there seem to be only minor 
engine influences. "

An addendum I sent today to the improve list:

"Contrary to the fact that PNG paintcompression may slow down the speed 
of imagedata processing considerably, "text-of-image" data are 
apparently not affected, as you can see when you use button "sample 
image - five sizes" of the test stack, which stores the image contents 
as text-of -image data."


--Wilhelm Sanke
 <http://www.sanke.org/MetaMedia>