[fpc-pascal] Performance problems with Image Conversions
atbrunner at aurawin.com
Sun Feb 24 18:35:37 CET 2013
On 02/24/2013 04:44 AM, Michael Van Canneyt wrote:
> Try to get rid of the XML, it is always going to be slow.
> Using XML can slow your applications with a factor 6.
> If you are mime-encoding an image, it'll be even more.
I was just thinking about that. I think JSON would be ok, especially if
I can use the RTL to get the data into the fields. XML code takes about
33% of my dbModules for each implementation. That would take a lot of
work for each DBModule and CoreObject, both client (js) and server(pas).
> Do a FreeAndNil(srcCanvas) here. 1. Free already checks if the pointer
> is not nil.
> You do not need to check again.
> 2. FreeAndNil will make sure the pointer is Nil
> 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.
Done. I'm preparing to check for performance gains...
> 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.
Ok, I noticed some units surrounding the graphic code. Is this
something that is illustrated on the wiki? Where do I get the methods?
Anyone else is welcome to comment on scaling methods here... I have a
feeling this would yield the most performance gains.
Digital Photos scaled go from 3264x2448 down to 512x384 so the scaling
is somewhat slow. The streaming is slow too...
If not, does anyone have lightning fast scaling methods in C++ or Java
that I can port/contribute?
More information about the fpc-pascal