[fpc-pascal] Performance problems with Image Conversions

[Sven Barth]

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...

Regards,
Sven