[Lazarus] fpimage use of Lazarus

[Marco van de Voort]

On Sat, Feb 16, 2008 at 02:32:24PM +0100, Mattias Gaertner wrote:
> Marco van de Voort <marcov at stack.nl> wrote:
> > In this context one should also see my "which properties" question.
> > If I expand TFPMemoryImage with scanline (because it has storage), I
> > couldn't use it in the readers or writers, because then they wouldn't
> > work anymore with tlazintfimage. So more or less you confirmed my
> > doubts, Lazarus is not using TFPMemoryImage.
> 
> Correct. TFPMemoryImage knows only one format. The LCL needs a flexible
> one, that supports at least all memory formats of all widgetsets -
> which afaik excludes only compressed and floating point memory formats.

> > So probably the ancestor class should get a scanline property with
> > some abstract methods, and TLazIntfImage needs to override that too.
> 
> TLazIntfImage.GetDataLineStart?

Exactly. Maybe a scanline property:
  property scanline[row:integer]:pointer  read getdatalinestart;

This is how I got so far:

- TFPCustomImage gets an scanline /getdatalinestart pointer that can get the
  address of the first pixel per scanline. The Lazarus derivative already
  has something like that, so I propose to use that function name.
- When reading, a reader must determine the bitcount per pixel (bpp), and
  pass it to an abstract virtual TFPCustomImage method which returns the
  actual bpp to be used. (the increment needed to get from (0,row) to
  (n,row). This allows one and the same reader/writer with different
  internal representations and supported bpp counts.  Working title for this
  function is supportbpp.
- The above supportbpp call (which must happen before the definitive 
   setsize) is the only thing that changes for existing
  pixel property based reader to be compatible with also newer
  customimages.
- The old situation (using existing readers/writers with existing
  tfpcustomimages remains the same.
- Since this is possible, I also leave TMemoryImage alone for compat, and
  make a new class for more efficient purposes. It only gets the scanline 
  support added, but always returns 32bpp as bitcount.
- Anyone accessing scanline must check the bpp property to determine the
  granularity.
- I'm still thinking about a property that signals scanline support. This
would allow readers/writers to fall back to pixels for special
customimages that don't support scanline.

So in short, scanline support is added with as only compat limitation that a
reader must pass on the bitcount before the main setsize. This avoids the
current situation that the image must allocate for the worst case situation.
Other changes only need fixing in existing fpimage usage if you really want
to use newer features.

This also allows me to fiddle around without hurting Lazarus too much, and
confirm that the scheme works with the existing supported formats.

In general it allows to speed up relative basic readers and writers a
magnitude (from pixel to row based) at the expense of more code in
reader/writer, but that is not forced. E.g. one could only optimize certain
many used cases of a graph format like this, and leave the oddball options
to the existing reader.  It also allows image formats to not allocate the
worst case amount of mem (maxbpp*rowsize*height).