[fpc-pascal] Implementing AggPas with PtcGraph

[James Richters]

>I have applied such a change. So far only to the Agg2D and agg_2D units, but I'll do the same to the rest of the units shortly.
That will be a great help.   Might I suggest mentioning the existence and use of Agg2D in agg_2D and vice versa?  Something like:

agg_2D
This unit has NO graphical toolkit dependencies, so is ideal for console or web based (server side) projects.    For the graphical full toolkit version, see Agg2D.pas

Agg2D: 
If you do not need to graphical toolkit (for example for console or web based projects, this dependency can be avoided by using agg_2D.pas

Something to that effect.  My reasoning of mentioning each in the other is because the names are so similar, yet it's difficult to know the other exists because agg2D is all the way at the bottom of all the agg_ units, while agg_2D is at the top of them all.   Mentioning the other unit and it's use may help clarify things.

I also think you have made enough changes to it to warrant version number changes.  


>I'm also strongly considering renaming the "render/software/" directory to "render/aggpas/". I'll mull this over for another day or two.

I like the proposed directory name.  I wonder if it really needs 2 directories, why not just render-aggpas/ or aggpas-render/  ?


>That is a fundamental bug in AggPas, and something I'll be fixing immediately in fpGUI's repository. As for the affects on other code and programs.
>I'll do some testing to see what exact affect it has, and then add some notes in the CHANGELOG document describing code-breaking changes and recommended fixes.

Since there are going to be changes that require adjustments anyway, I wonder if it would make sense to just make agg_2D always require the pixel format in the constructor:

constructor Agg2D.Construct_PF(pixfmt:define_pixfmt); 

It seems the original intention of aggpas was to have this flexibility but somewhere along the way things like rgba ended up getting hard coded into it.

>I have always been in the mind that fundamental code and API's should be 100% correct, and fixed promptly when a bug is found. Applications that are affected
>by such changes need to be updated - that's the bottom line. No point in continue maintaining buggy code and API's and guaranteed that things will just get worse
>in the future - if not immediately fixed.

I agree with you, and if the changes for common issues are well documented then it seems to be the best solution.  I was trying to think of a way to adjust the unit and maintain backward compatibility, but it just ends up making a mess of everything.  Better off to just fix it then fix any programs as needed instead of having an even bigger and more confusing mess that no one will remember why it's like that in 5 years.

James