[fpc-pascal] Performance problems with Image Conversions

Sven Barth pascaldragon at googlemail.com
Sun Feb 24 12:47:21 CET 2013

On 24.02.2013 12:43, Michael Van Canneyt wrote:
> On Sun, 24 Feb 2013, Sven Barth wrote:
>> On 24.02.2013 11:44, Michael Van Canneyt wrote:
>>>>      srcImg:=TFPMemoryImage.Create(0,0);
>>> Do not use TFPMemoryImage. It is a catch-all memory format, not
>>> optimized at all, using 64 bits for the images.
>>> Instead, use e.g. TFPCompactImgRGBA8Bit if you need alpha or
>>> TFPCompactImgRGB8Bit if you do not need Alpha.
>> Nice, I did not know we have more compact image types available. O.o
> If memory serves well, Mattias Gaertner made them.

According to the SVN log your memory is correct. :)

>>>>          dstImg:=TFPMemoryImage.Create(iX,iY);
>>>>          dstImg.UsePalette:=false;
>>>>          dstCanvas:=TFPImageCanvas.create(dstImg);
>>>>          dstCanvas.StretchDraw(0,0,iX,iY,srcImg);
>>> Phew, this is also a real killer.
>>> Do not draw on a canvas with stretchdraw. That will be slow as well;
>>> Rather, attempt to manipulate the image in memory by doing a stretch
>>> directly.
>>> Choose an algorithm which is fast. The default interpolation will result
>>> in quite a lot of calculations.
>> Maybe a collection of algorithms for in memory rescaling would be nice...
> There are a lot of them, that is what the interpolations are for, but
> they work with a canvas. The case of rescaling an image and simply send
> the resulting image as a file was not foreseen at the time of writing.

It seems that it would be good if we'd refactor the interpolations then 
so that they can be used with either a canvas or an image as destination...


More information about the fpc-pascal mailing list