Submitted by The Amanith library is a cross-platform (Linux, Win32, MacOS X, FreeBSD and IRIX) open source C++ framework for vector graphics. The new 0.3 release adds a full SVG 1.2-compliant enhanced alpha compositing layer, supporting all 24 compositing operations (base and extended Porter-Duff) in pure OpenGL. This makes Amanith the first opensource and crossplatform library that supports all of them in hardware (15 of 24 are available also without fragment programs). In addition a full geometry caching system has been introduced to speed up all drawing tasks. Version 0.3 has been released today.
Anyone care to explain why a project like Amanith would want to license under the QPL? I read their license page[1], but it didn’t really give any specifics.
[1] http://www.amanith.org/include/licence.php
They would like to make some money with it?
Looks like they are using QT. So it’s not strange that they have to use QPL.
http://www.amanith.org/tutorials/index.php
… I still prefer cairo. The main issue I have with Amanith is the missing ability to use different rendering-backends. With cairo’s capability to render to/with Xlib, Render, PNG, PS, PDF, Quartz, GDI and glitz/OpenGL (yes, I know these backends have not all reached 100% maturity yet) is making its use-possibility more versatile IMO. Of course, personally, I’m only interested in two or three of those backends, but still, other people will very likely have different requirements for a vector-graphics API. Though in terms of performance and rendering-speed Amanith currently surpasses a cairo/glitz combo. But then, I haven’t done any scientifically sound comparision-benchmarking. It’s just an observation I’ve made for some things I tried out, which boil down to running the supplied examples and own pieces of code. In the end I think it’s easier for cairo to get further speed-boosts, then it is for Amanith to alter their architecture to support multiple rendering-backends. Also worth to note is the fact that it’s not totally sane to compare a 1.0-product to 0.3-product.
Afterall I’m glad to see both projects enriching the development-landscape of OpenSource-systems with vector-graphics technology!
Best regards…
MacSlow
Amanith drawboard (the rendering engine) architecture is ready to support more backends then the OpenGL one.
We have chosen to implement the OpenGL backend as first because we trust that hardware acceleration will be the future in this application field; its crossplatform soul makes OpenGL the ideal choice for the first stage of Amanith development.
Regards,
Michele Fabbri – Amanith Team
Oh… *cough* I have to take a closer look again
Aside from OpenGL do you support any other backend out-of-the-box then? Just curious.
Thanks in advance!
Best regards…
MacSlow
Yes, we have in our roadmap some other backends (direct3d, first of all), but the idea is to finish the OpenGL one before to start to code another one.
Tecnically, as u can see in /src/rendering/ , write a backend is just a matter to derive a class from gDrawboard, as we have done with gOpenglboard.
It would be cool if the community will help us developing backends, but, i know, we are qpl, so i don’t expect so much.
Regards,
Michele Fabbri – Amanith Team
I think that a comparison is not easy.
There are several features present in Amanith and absent in all available similar libraries on the market.
From a performance point of view: we think that the future of 2D graphics is in hw. Amanith has been thinked with this concept in mind. Every algorithm, every choice has been made to gain the best performance on accelerated gfx boards. This is the BIG difference from a classic gfx library, where hw acceleration is there just as a “backend” option, under all the compromises that the library needs to support, for example, several kind of backends.
To conclude, Amanith isn’t just a rendering library. Under the skin there is a good geometric kernel and a rich set of classes to work with animations, curves and so on.
To understand it in a better way, you can have a look at this document http://www.amanith.org/test/amanith.pdf
>To understand it in a better way, you can have a look at this document
I’d like to, but the link is broken..