Marco van de Voort <mar...@stack.nl> hat am 21. April 2011 um 18:50
geschrieben:
> In our previous episode, michael.vancann...@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
> this,
> and within the fcl-image I've found no solution without invalidating the
> concept.
>
> 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
> parameterize
> 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;
begin
for y:=10 to img.Height-10 do
for x:=10 to img.Width-10 do
img.Colors[x,y]:=colRed;
end;
>
> 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
memory formats.
Mattias
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
