A TBGRABitmap is an actual image class that behaves like you would expect an image class to behave (i.e. with full SaveTo, LoadFrom functionality, e.t.c.)...
And that is where I fundamentally disagree with such designs. In your above text you now mention that a 2D graphics library also does file handling, unicode or code page conversion of file names, file format handling, streaming etc... That's an awful lot of non 2D graphics functionality thrown it.
You can use LoadFromStream if you don't want to use LoadFromFile. And having no ability to read a stream, you would like a class that just takes pointers? And if really you don't want any of the reading mechanism, you can still make your own framework and call the SetPixel function.
Also it is not fair to say that file format handling is in the class. There are readers and writers, directly from the FreePascal readers/writers for image files or based on the same abstract class. You can define your own reader if you like.
My design philosophy: Keep it simple and let each class do one thing only, and do that thing very well.
I don't find AGG to be simple personally. I would agree that classes are small, but not that they are simple to understand.
My philosophy is rather: if someone wants something, let's give it. If someone wants something a bit more special, let's give the components to do that. So every feature is as much as possible given a simple function, that enables to use it without understanding its inner workings. There may be some things you cannot do with the provided functions, but then, you can simply dig a bit further according to how motivated you are to do so.
It's also exactly the reason I hate LCL's TStringGrid's LoadFromCSVFile() method. What
if I wanted to load from a JSON or XML file?
You don't need to hate it. You can ask to have readers and writers just like for images or provide a patch that would do that.
Also LCL's TListView - is that a list, grid, report etc component? Too much
functionality in a single class and makes in very prone to bugs.
Are you worried about bugs and you find it reassuring that AGG classes are small and that would prevent bugs?
fpGUI's StringGrid "load from CSV file" solution is a separate TStringGridBuilder
class that takes a StringGrid as a parameter. CSV, JSON, XML etc functionality is kept totally separate
from the TfpgStringGrid class.
That's good. And you don't need to hate LCL version to value your own version.
I have no interest in 3D at all, so I'll leave that exercise for somebody else to play with. But like Circular mentioned, AggPas already has rotate, transform, perspective functionality, so it shouldn't be hard to implement a TAgg3D class.
Yet that would still be a lot for a user that does not have hours to spend on that. Basically you are saying AGG is better because it lets you program something, but that's not an actual fact, that's a potential. It is like saying a big promise is better than an actual gift.
TAgg2D was actually added much later to AGG - simply to show that you can implement a all-in-one Canvas like class. It was never meant for day-to-day usage. But as I've come to realise, so many developers are engrained with the idea of one class must be able to do everything so many tend to use TAgg2D instead of exploring the powers of loosely coupled features.
I hear two things. That you are sad that people are not more using the loosely coupled features. On that I would tend to be also enthusiastic about people trying to use the more specialized class of BGRABitmap. The other thing I hear is that you say the developers don't use them because they are mentally conditioned. On that I would say that yes there are habits, but the more fundamental reason is that it takes time and energy to learn to use loosely coupled features. When you are focused on achieving something, having to program everything at a low level can become an obstacle to your creativity.