[fpc-pascal] FPImage and GetDataLineStart

[Mattias Gaertner]

 Marco van de Voort <marcov at stack.nl> hat am 21. April 2011 um 18:50
geschrieben:

 > 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
 > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20110421/5366053a/attachment.html>