[Lazarus] fpimage use of Lazarus

[Mattias Gaertner]

On Sat, 16 Feb 2008 17:35:13 +0100
Marco van de Voort <marcov at stack.nl> wrote:

> 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).

You only mention bpp. What about the other 14 properties to describe a
row?

Mattias