[fpc-pascal] FPImage and GetDataLineStart

[Marco van de Voort]

In our previous episode, michael.vancanneyt at wisa.be said:
> >>> IMHO it is the long term solution. Anything else would be madness, or minor
> >>> damage control at best.
> >>
> >> Most of the more "recent" or "new" languages I know do not have generics,
> >
> > What do you mean, C++,C#, Java ?
> 
> No, they are "old" languages too. I was more thinking in terms of 
> PHP, Ruby, Python, Javascript (and its variations). I haven't come 
> accross generics for these languages. Yet they are widely adopted.

Ah, I don't considered those languages. At least not where any discussions
about performance or efficiency apply ;_)

So, I'm afraid I'll have to bounce the earlier request to cut the retoric
back to you.
 
> > It eases some cases where that strictness hurts. There are multiple
> > solutions for such cases, e.g. in the database world, people went for
> > variants.
> 
> I have a database with over 7000 fields, another with 3000, for neither
> variants are used. Maybe I misunderstand your statement.

The point was about that not every relaxation of the typed regime is generic
based. It is about choosing the right relaxation for the right application.
 
.. 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)

> > They are as subjective as a one person mandated ban on generics. Even long
> > term.
> 
> Exactly, which is why the discussion was leading nowhere :-)

There never was a discussion. Apparently the result was preset. Not the
healthies of principles btw. I counted in SVN btw, 20 commits for you, 17
for me in fcl-image, though several of mine will probably mostly touch makefiles
and fpmake restructures.
 
> > I see no workable solution at this moment. So I'll wait what you have to
> > offer, and see if it matches my own.

(and with these principles I'm 100% positive that it won't btw. This was more the hope that it
will at least match enough to use it for secondary goals and/or recycle
readers and writers with relative minimal efforts)

> > Otherwise I'll see if I can create some
> > parallel base library, but that has to wait till generics on FPC are more
> > mature.

Where I should remark that even D/XE is borderline readiness atm.
 
> Meanwhile you can help by supplying me with a test image file that takes
> too long to load.  I recall you said something about seconds.  Since all
> the ones I use load in acceptible times, I'd like to see one where things
> go badly wrong.

The next time I work on my libs, I'll do some testing and see if I can start
building a lib of interesting cases. There are several bugs in mantis too
btw, mostly dealing with alpha.

But IIRC it was converting 4096x7000x8bpp bmps to png. I was compressing our
archive of BMPs, and used imgconv to provide a baseline to test my own png
writing routines (a line based simplification of the current
readers/writers) with.

I also have a vague recollection of some troubles with topdown images,
probably 16-bit bmp grayscale, but can't remember the exact details.