<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"/>
    <title></title>
  </head>

  <body>
    <p style="margin: 0px;"><span> </span></p>

    <p style="margin: 0px;"> </p>

    <div style="margin: 5px 0px 5px 0px;">
      Marco van de Voort <marcov@stack.nl> hat am 21. April 2011 um 18:50 geschrieben:<br/>
      <br/>
      > In our previous episode, michael.vancanneyt@wisa.be said:<br/>
      > > * Create a TFPCustomImage descendant that is limited to the bit depth you need.<br/>
      > > * Do not use palette.<br/>
      > > * Implement GetPixel and SetPixel so they convert from 64-bit from/to the depth you used<br/>
      > > * Implement a GetScanLine/SetScanLine specific to your bit depth.<br/>
      > ><br/>
      > > You can now load/save the image very fast using the GetScanLine/SetScanLine,<br/>
      > > and all other FPIMage operations will work equally well.<br/>
      ><br/>
      > This will not accelerate reading/writing at all. When writing (or any other<br/>
      > form of streaming), there will still be a procedure call per pixel and<br/>
      > conversion to/from 64-bit.
    </div>

    <p style="margin: 0px;"> </p>

    <p style="margin: 0px;">Yes, it does, because of cache effects.</p>

    <p style="margin: 0px;">I use it my programs and a 32bit per pixel fpmemoryimage is about twice as fast as a 64bit per pixel. </p>

    <p style="margin: 0px;">And 24bit RGB or 8bit grayscale is even faster.</p>

    <p style="margin: 0px;"> </p>

    <div style="margin: 5px 0px 5px 0px;">
       <br/>
      > However I've done some attempts and research to see what it would take to fix this,<br/>
      > and within the fcl-image I've found no solution without invalidating the<br/>
      > concept.<br/>
      ><br/>
      > The only sane solution (long term) is to convert fcl-image to a generic<br/>
      > class, and make some of the aspects generic.  (e.g.  for a yuv422 image you<br/>
      > need to define a record with several inline static methods and then parameterize<br/>
      > some generic yuv class that is a descendant of a generic 8-bit storage<br/>
      > class etc) with that record. (the generic yuv class then knows what methods<br/>
      > to call, and are somewhat efficient due to the inlining)
    </div>

    <p style="margin: 0px;"> </p>

    <p style="margin: 0px;">Can you give an example, how this should work?</p>

    <p style="margin: 0px;">For example, how would you alter the following routine:</p>

    <p style="margin: 0px;"> </p>

    <p style="margin: 0px;">procedure PaintSomething(img: TFPCustomImage);</p>

    <p style="margin: 0px;">var x,y: integer; </p>

    <p style="margin: 0px;">begin</p>

    <p style="margin: 0px;">  for y:=10 to img.Height-10 do  </p>

    <p style="margin: 0px;">    for x:=10 to img.Width-10 do  </p>

    <p style="margin: 0px;">      img.Colors[x,y]:=colRed; </p>
    end; 

    <p style="margin: 0px;"> </p>

    <p style="margin: 0px;"> </p>

    <div style="margin: 5px 0px 5px 0px;">
      ><br/>
      > The fun part is that you can still implement the current way as baseline<br/>
      > this way, and then progressively implement quicker variants.
    </div><br/>
    Note: TLazIntfImage already contains a lot of access functions for many common memory formats.<br/>
    <br/>
    Mattias<br/>
    <br/>
  </body>
</html>