[Lazarus] fpimage use of Lazarus

[Marco van de Voort]

On Sat, Feb 16, 2008 at 07:15:05PM +0100, Mattias Gaertner wrote:
> > On Sat, Feb 16, 2008 at 05:35:13PM +0100, Marco van de Voort wrote:
> > 
> > Addition to self:
> > 
> > I've studied intfgraphics some more and my scheme means that maybe
> > some lazarus specific tricks need less lazarus specific implementation
> 
> Great.
> What tricks?
> Keep in mind that the goal of TLazIntfImage is to eventually access
> directly the widgetset images instead of copies. Of course this can
> only work on some widgetsets.

Well, it is partially exactly like that. It just pulls the defining
parameters (width, height, bpp, rowpitch (aka bytes per row) of the storage
requirements into the abstract class. Not the storage itself.

If the storage of a native type can be descibed like that, a laz specific
image can still store in the native struc, but use the normal readers and
writers.

So to summon up, the storage properties and assumptions are:

1. width + height in pixels
2. size of a pixel in bits. If pixels are non packed (24-bits stored as
  32-bit), this is about the _actual_ storage value, so 32-bit.
3. size per row in bytes or pixels. (alignment reasons) I'm used to pixels,
  but maybe bytes is better.
4. If one has the address of the first pixel of a row, the address of the next
  pixel can be calculated by adding the amount of bits. (bitpacking into
  account)
5. a property that signals if 1..4 hold true. If not the reader/write must
   revert to the current (pixel based) behaviour.

The 4th condition goes wrong if e.g. byte arrays are stored as integer
arrays on little endian systems, then you get

b3 b2 b1 b0 b7 b6 b5 b4 ... etc.

I don't know if there are fileformats who do this (hope not), but if they
do, it is the readers responsibility to revert to "per pixel" addressing via
the pixels property.

I'm thinking about adding a property that signals if you can jump between
rows by adding a fixed amount of bytes (usually bytesperrow, but maybe
negative). But I'm not doing that until I at least have
implemented the above.

> > mask support is not needed in bpp. Bytesperline is probably a similar
> > crucial param as bpp, so I propose to pull this into fpimage too.
> > (supports (var bpp, var bytesperline));
> 
> I still wonder what happen to the other properties, like depth, bit
> order, rgb order, alpha depth, etc.

Those are all to interpret pixel data (depending on what you mean by depth).
Not to extract or allocate storage.

Note that this is all still just about the pixel data. 

One of the reasons that laz has own readers and writers seem to be palettes.
I'm still investigating that. This is all just in the "sparring and
brainstorming" stage.