[fpc-pascal] FPImage and GetDataLineStart

[Marco van de Voort]

In our previous episode, Michael Van Canneyt said:
> > Ah, I don't considered those languages. At least not where any discussions
> > about performance or efficiency apply ;_)
> 
> The topic was the availability of generics. 
> In that field, all languages are viewed.

If you say so. Anyway, while I could try to create debate here (age of those
languages, as confirmed by other reply, finding references about generics
and generic-equivalent constructs in them), I'm not even interested enough
in those languages to bother. At least not in FPC related language design
context.
 
> > .. or is your database layer entirely strong typed? If so, you might want to
> > talk to Frank H. of GPC, he is afaik also strongly in favour of such
> > approach. (and that is not meant in disrespectful way, though it is a bit a
> > specialty IMHO)
> 
> I don't know what you mean by 'strongly typed database layer', but the
> contents and type of each field is known.  Elementary RDBMS and some level
> 3 normalization.  No 'no sql' for me.

Right. Should have said statically strong typed. Not related to RDBMS, but
the lack of a generic db layer that requires runtime typing. Usually
achieved by generating a lot of source with a preprocessor.

Because that was my point. Runtime typing (variants, array of const,
idispatch) are IMHO more dangerous and against pascal principles than
generics, which are still statically and strong typed.

>From what I see I do realize generics generally do have a rather difficult
implementation.  But we didn't hold back to the massive changes of the base
Delphi dialect either, so that in itself is IMHO not enough reason to njet
it.
 
> >> Exactly, which is why the discussion was leading nowhere :-)
> >
> > There never was a discussion. Apparently the result was preset.
> 
> You asked about my motivations, I gave them.

I haven't seen anything that has relevance in FPC context.
 
> In each case, I think I have an approach which should speed things up, and
> still sticks to the design principles of fpImage.

The only design I see in fpimage is a general effort to try to support
anything at once. Nevermind the costs.

And actually, back in the days, that was not a bad thing to have.
 
> I checked your code, and it throws overboard much if not all that fpImage
> was designed for.  I'm aware that I'll probably never match what you had
> in speed terms, but then you made some very limiting design choices which
> I simply don't want in fpImage.  The price of more generality is some
> speed loss, it is always so.

I don't see the need for that. I just want to keep a handful of generic storage
types very fast and seperately usable, just like we essentially have one
storage type (64-bit RGBA) now.  This for image manipulation.

Then expand the readers/writers to optionally operate rowbased, and have a
few codepath simplifications in them (e.g.  try to avoid the copying of
rowdata to local arrays to facilitate compression and filtering in e.g.  PNG
if you don't use either), so that they essentially get zero-copy
possibilities.  I'm thinking about png, bmp and maybe jpg here.

This also has consequences for reader errorhandling, it should be possible
to pass a 16-bit (e.g.  RGB555) memory image to a reader, and have the
reader throw an exception or terminate with errorcode if the pic to load
requires something bigger.  (or we need a "peek" approach, to first open the
image and determine the format, then allocate to custom load the memory
image, and only then load it).

Another annoying one that should be tackled whatever choice is made, is at
least being able to override the compression level in the pngwriter.  It is
now always clmax which is IIRC the slowest way.  (and for "photo" data, the
gains are very small and not worth that).

All the rarer ones keep working on the 64-bit RGBA16 base type as it is now,
pixel oriented etc. I planned to see if something could be done for them
after the main restructuring.

A problem that I haven't thought up a solution for is autodetection of the
format to safe. There have been mantis bugs about this (iirc one by Felipe),
namely if you write an image you need to set options, and if you used canvas
that might not be the same options as received from the image when read
(e.g. a 257th color has been used, making palette impossible)

But all this is guesswork, since you don't detail the problems with my
approach except that you won't use generics at work, and you haven't
detailed your own more than that you plan to accelerate it (but not too
much) and use delegation. And of course stick to a design philisophy that is
detailed nowhere.

I put that crude intentionally. Since we are not going to concur at this
point, it seems you'll go ahead, but I hope that it provides an incentive to
be more open with it, and have some public resources. (there is a page for
fcl-image in the wiki)

> I would appreciate getting the really slow images if possible.
> 
> If there are still bugs in bottom-up images, I'd like to hear about them
> too, but they are an issue separate of the loading times issue; Probably a
> reader problem.  As far as I know, bottom-up reading is supported for BMP.

It's a while ago (early last summer), and a bit in fall when XE came out.
But soon I'll be picking this up again.