[fpc-pascal] FPImage and GetDataLineStart

[Michael Van Canneyt]

On Sat, 23 Apr 2011, Marco van de Voort wrote:

> 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 ;_)

The topic was the availability of generics. 
In that field, all languages are viewed.

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

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.

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

You asked about my motivations, I gave them.

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

Discarding initial design (there is no trace of that in SVN for obvious reasons),
here is how I made my count:

home: >cd fpc/packages/fcl-image/src/
home: >foreach f ( *.* )
foreach? svn log $f >>log
foreach? end
home: >grep '^r' log | sort | uniq | wc -l
69
home: >grep '^r' log | sort | uniq | grep michael |wc -l
34
home: >grep '^r' log | sort | uniq | grep marco | wc -l
14

In each case, I think I have an approach which should speed things up, and still
sticks to the design principles of fpImage.

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

Michael.