[fpc-pascal] Performance problems with Image Conversions
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:
>>> 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. :)
>>> 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
>>> 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