[fpc-pascal] FPImage and GetDataLineStart
nc-gaertnma at netcologne.de
Thu Apr 21 19:10:18 CEST 2011
Marco van de Voort <marcov at stack.nl> hat am 21. April 2011 um 18:50
> In our previous episode, michael.vancanneyt at wisa.be said:
> > * Create a TFPCustomImage descendant that is limited to the bit depth you
> > need.
> > * Do not use palette.
> > * Implement GetPixel and SetPixel so they convert from 64-bit from/to the
> > depth you used
> > * Implement a GetScanLine/SetScanLine specific to your bit depth.
> > You can now load/save the image very fast using the
> > GetScanLine/SetScanLine,
> > and all other FPIMage operations will work equally well.
> This will not accelerate reading/writing at all. When writing (or any other
> form of streaming), there will still be a procedure call per pixel and
> conversion to/from 64-bit.
Yes, it does, because of cache effects.
I use it my programs and a 32bit per pixel fpmemoryimage is about twice as fast
as a 64bit per pixel.
And 24bit RGB or 8bit grayscale is even faster.
> However I've done some attempts and research to see what it would take to fix
> and within the fcl-image I've found no solution without invalidating the
> The only sane solution (long term) is to convert fcl-image to a generic
> class, and make some of the aspects generic. (e.g. for a yuv422 image you
> need to define a record with several inline static methods and then
> some generic yuv class that is a descendant of a generic 8-bit storage
> class etc) with that record. (the generic yuv class then knows what methods
> to call, and are somewhat efficient due to the inlining)
Can you give an example, how this should work?
For example, how would you alter the following routine:
procedure PaintSomething(img: TFPCustomImage);
var x,y: integer;
for y:=10 to img.Height-10 do
for x:=10 to img.Width-10 do
> The fun part is that you can still implement the current way as baseline
> this way, and then progressively implement quicker variants.
Note: TLazIntfImage already contains a lot of access functions for many common
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fpc-pascal