On Sat, 16 Feb 2008 17:35:13 +0100 Marco van de Voort <[EMAIL PROTECTED]> wrote:
> On Sat, Feb 16, 2008 at 02:32:24PM +0100, Mattias Gaertner wrote: > > Marco van de Voort <[EMAIL PROTECTED]> 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 _______________________________________________ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
