Hi,
Behdad Esfahbod schrieb:
> Milan Marusinec wrote:
>
>>>> Free Software projects typically find much more than 10000 quite easily, by
>>>> engaging the masses.
>>> Not only that; there might be people much more experienced and
>>> efficient than you, they might just be able to do the job in maybe
>>> 1/10th of the time.
>> To be honest, I am really really wondering, where that "masses"
>> are for the AGG case. AGG is a gem of the world (anyone not agreeing ?).
>
> AGG is technically very advanced, but it seems to have failed in community
> building and gaining widespread adoption. If it was a human, it would have
> been a nerd.
I agree that using AGG in your projects has quite a learning curve at
first. The very usage of templates may be an obstacle to the "casual C++
programmer". However, that is also where AGG draws most of it's power
and flexibility from. So it cannot be changed without losing the very
essence of what AGG is.
>> And I am asking, where is the volunteer crowd supporting AGG
>> with fractions of their free time ??? Is it not worth it ???
>>
>> And to be honest even more, the only persons who created AGG and
>> supported AGG (as FOSS) is Maxim Shemanarev himself(*). I joined his
>> endeavour when I ported his gem to the Object Pascal and I have also
>> contributed to the C++ version (http://milan.marusinec.sk/aggcp/).
>> (not to mention I have also documented Agg2D for free).
>
> Well. On the other hand look at cairo. Cairo and AGG try to solve the same
> problem but they take very very very very different approaches. Cairo's main
> focus is being user-friendly. We believe that users MUST have fun using
> cairo. If they don't, it's a bug. Performance is not the top priority for
> us. From what I understand, AGG on the other hand is designed to be
> configurable and high-performance to the end.
>
> I don't want to brag about cairo too much, but lets take a look at the stats:
> Cairo was started in 2002, and these days has backends for memory buffers,
> Xlib, XCB, Win32, Quartz, Postscript, PDF, SVG, glitz, BeOS, DirectFB, and
> OS/2. Patches exist for OpenVG and QPainter backends. Cairo has bindings for
> C++, Common Lisp, D, Haskell, Java, .NET, Nickle, O'Caml, Perl, PHP, Python,
> Ruby, Scheme, Squeak, and except for Nickle, the rest were not written by core
> cairo developers. And to date, more than 250 people have contributed patches
> to cairo. Cairo is the base 2D drawing library used by GNOME, and by Firefox 3.
I disagree. Cairo and AGG are not exactly solving the same problem, only
when looking from 10000ft. Just by what you say, you can already see the
difference. Cairo is an API. AGG is an engine. To put things into the
right perspective, one could say that AGG could be one of the backends
of Cairo. And AFAIK, this is indeed what has been done before. From what
I understand, people have wrapped APIs around AGG, when they "ported" it
to other languages like Pascal or C# (although I may show my ignorance
here, please correct!). This means you get to use what the API offers,
but not the whole flexibility of AGG.
In my own projects, I have used AGG either way. Sometimes I would use it
directly, as a quick solution to a problem. Some other times, I have
used it as the backend to an API I designed. When you do this, you limit
the features of AGG to what your API offers. AGG usually can do much
more than that. I am usually using a very small subset of what's
possible with AGG, in any API I designed.
And this may be why we see so little contribution to AGG. My own
contribution has been a BeOS port of the AGG example platform support
code. I don't think I contributed to the core AGG library. It's just so
damn feature rich, you'd be hard-pressed of thinking something to
contribute.
To this day, I have been missing only one thing in AGG, and that is LCD
sub-pixel based anti-aliasing. I have worked on various graphics
projects both closed and open source, and none have had any requirements
that could not be fullfilled with AGG. AGG never gave me any troubles,
though other people have hit small bugs and have sent patches to this
list. However, I have always been able to 100% rely on AGG. There have
never been any leaks or crashes or any other problem whatsoever. Really,
the only feature I wanted, which is not included in AGG yet, is
sub-pixel anti-aliasing.
One of the projects I used AGG in is the Haiku operating system. The
application server, which is also responsible for implementing the
drawing API, uses AGG as a backend. Last year, Haiku was part of Google
Summer of Code again, and my student implemented the sub-pixel
anti-aliasing. He did this by extending AGG itself. I am happy to have
been accepted as one of the AGG contributors. And I am planning to
contribute this code back to AGG. (Although it's free for anyone to use,
who cares to look at the open source, MIT licensed Haiku operating system.)
AGG is just so damn flexible, I actually wouldn't know what to code on.
That may actually be the same feeling that many other people have. Even
in some very advanced and demanding projects, you'd be hard pressed to
hit a requirement that cannot be fulfilled by AGG.
>> Did you contributed to AGG a line of code ?
>
> No. I never got to learn it. I have been busy with the other FOSS projects I
> contribute to.
Same here, although I use AGG again and again in any new project.
>> (If not, why are you watching so closely this AGG list ?)
>
> I learned about AGG by reading Maxim's article on text rasterization:
>
> http://antigrain.com/research/font_rasterization/index.html
>
> As you may know, text rendering is my main expertise. My attention was drawn
> to AGG again when talking to Miguel de Icaza about how they use cairo in
> Moonlight for most of the stuff, but for some stuff cairo is simply too slow
> or otherwise performs badly and they have to use AGG.
I don't suppose it would be very hard to make a Cairo backend using AGG.
That should make the performance the same.
> Based on the above two experiences I figured that AGG is a worthwhile project
> and I subscribed to the list to follow its development, as I do with any other
> project I develop an interest on.
>
> I have fancied incorporating some algorithms from AGG into cairo some day, but
> have not got to 1) check the license compatibilities, 2) find useful code I
> can lift, 3) convert from C++ to C.
You can't convert it to C. The whole concept is based on C++ templates.
I guess that Cairo needs to use C so the other languages can bind to it.
But this is the wrong place to look when trying to incorporate some AGG
code into it. Just make an encapsulated backend using AGG. There is
nothing else you can learn from AGG as long as you provide a fixed API.
>> I am personally very very sad, AGG is going to die.
>> (Judging by the activity over the last year and half).
>
> That is indeed sad.
I don't think it's going to die. I think it's just so damn feature
complete, it will be a while before someone is pressed hard enough to
extend it.
> I think one of the problems with AGG was that it never got the leverage to
> gain widespread use. Cairo was adopted by GNOME and got widespread use that
> way. QPainter is used by Qt. Skia is used in Android. A worthwhile question
> is, who is the AGG's audience, other than those looking for a quick, free,
> piece of code to get their job done?
I think AGG is being deployed much more often than you think. The
audience are developers who can grasp the power of the raw AGG code, or
who can wrap their own API around it. If Cairo was to have an AGG
backend, then that would be an example of how AGG is supposed to be
used. People would use Cairo without even realizing that they also use
AGG (if they happen to use the software backend).
Best regards,
-Stephan
|