lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

> I think the AGG library is unmaintained? A plotting library for Lua is
> very useful but dependency on unmaintained libraries is a problem.
> This was a blocker for me when I looked at your plotting library
> before.


thank you for asking. I will take this opportunity to discuss about
the AGG library, I understand it can be a concern for some people.

It is true that the AGG library is no longer maintained. Some peoples
are providing fixes for some minor problems but it still remains that
the library is unmaintained. Yet a think that to some extend it is
still ok to use the AGG library for the main reason that the AGG
library is essentially done and well-tested. It provides algorithms
for rendering geometrical figures and perform anti-aliasing rendering
using generic template-based C++ code. As he code is essentially about
algorithms, geometry and rendering to a pixel buffer it will not gets
outdated anytime soon.

But I admit that still there are some concerns. For example C++ has
evolved with C++11 and later and the AGG library will not get adapted
to use them. On the other side I know the AGG's C++ code and I know
that it doesn't need to be updated for C++11 and later as the features
of C++ it uses, templates and classes, are already well established
and did not essentially changed with C++11 and later.

Another concern is that the AGG library is only CPU-based and does not
take advantage of the GPU. This is true but in reality there is
nothing that prevents you from using the GPU for composition and to
display on a window. The only thing that you will not get is to
perform the geometric and rendering operations of AGG in the GPU bu to
me this is not a major concern. One has also to consider how
fragmented and ugly is the current state of GPU rendering pipeline. In
term of engineering effort you need a team of dedicated engineer to
make things work smoothly over different openGL standards, ARB
extensions, driver bugs and OS specificity, Direct3D on Windows, Metal
on Mac OS X etc.

The reality is, for a single person project you cannot afford to
embark in the GPU-accelerated stuff, anyway. Even ready-to-use
libraries like Skia, used for graphics rendering in Chrome, are so
complex that even just to compile them is an endeavor. This means they
bring a huge amount of engineering complexity the Google can afford
but a modest open source project can not.

So, to resume by thoughts, AGG library is ok to use even if it is
unmaintained because is a mature and well-tested collection of C++
algorithms for geometry and pixel rendering ans this stuff is not
going to get outdated anytime soon. Other features like GPU based
composition, window system, event handling does not depends on the AGG
libraries but it is to the Elementary Plot library to provide them and
we can use whatever other libraries we need.

> Also why not create plain Lua bindings instead of using sol2? I think
> using any intermediate layer makes your library less usable, as not
> everyone will use sol2.

I am not sure that I made a good decision but I loved sol2 because it
spared me a lot of work to have is almost no time working Lua bindngs
to the C++ code. Create plain Lua bindings is okay but it takes a lot
of time. My idea is that sol2 is easy to install if you want to
compile the library and once the library is compiled, for example like
a dll, you don't need sol2 anymore.

This may change in the future but for the moment sol2 looks "good
enough" for me.

Kind regards