I got a first functional release for ggiart at:
http://soyt.free.fr/ggi/ggiart-0.1.tar.bz2
Note that ggiart requires libart_lgpl. You actualy need it to build your
paths. ggiart is just a rendering backend for ggi visuals.
------------------------
libart summary:
libart has two main parts: a set of functions that handle vector paths
logicaly (path construction, intersection, affine transorms,...) and a set
of functions on rgb or rgba arrays (rendering of vpaths, affine transform and
alpha-compositing of buffers). All rendering operations are done on 8 bit
rgb(a) or gray linear buffers.
problems:
- no acceleration possible for tha actual drawing
- different targets require api duplication in 'user space'
(rgb_, rgba_, gray_)
So the idea is to use the ggi abstraction for color and visual to
get a consistent rendering api and allow possible acceleration.
For now, ggiart is only capable of rendering sorted vector path, both alpha
and antialiased. I still need to work out a proper ArtRender abstraction,
and the api for alpha-compositing and affine transorm of pixel buffers
(and/or ggi_visual, kind of cross-blitting ?).
The good thing is : the default stubs should work on _any_ visual, even
those without a linear framebuffer. Now it can definitely be accelerated
(at least through directbuffers).
This leads me to this question:
I suppose that some hardware allow to draw point or lines with an alpha
value. Since ggi_color defines an alpha channel, why don't basic ggi
drawing functions handle alpha-compositing internaly?
Thanks for feedback.
Regards.
