LibArt's overall architecture

Using libart

Using libart to display vector graphics on screen can be a pretty difficult task for beginers: libart was not designed to draw vector graphics on screen. It was designed to draw graphics in pixel buffers. It is up to the reader to draw those pixel buffers on screen after rendering.

The diagram above shows how you could use libart: the pixel buffers can be stored -they could be also manipulated before doing so- but they can also be rendered on screen using GTK+' Gdkrgb code.

Some sample code shows how to achieve both of those scenarios by hand, but application developers should remember that it is pretty unlikely that they will have to do this. Higher-level APIs which deal with structured vector graphics are available and they take care of all the rendering of the vector data you feed them. The GnomeCanvas can be used for this: its antialiased version uses libart to render vector data in pixel buffers and Gdkrgb to render those pixel buffers in X windows.

From vector data to pixel buffers

Libart's vector input is described using 2 data structures: ArtBpath (short for Bezier Paths) and ArtVPath (short for Vector Paths). libart provides a number of helper functions to manipulate these data structures and instantiate specific geometric shapes easily.

To render these data vectors to a pixel buffer, libart wants you to transform them in ArtSVPs (short for Sorted Vector Paths). Svps are a rendering-friendly version of the original vectors. I would strongly suggest against constructing your own svps by hand without using the libart's construction APIs: these SVPs need to verify a number of properties which are not trivial and I have no idea what would happen if you passed a corrupted svp to the rendering code (probably bad things)... For example, art_svp_from_vpath will generate the svp corresponding to your vpaths.

Once you have constructed your svps, you can manipulate those svps before rendering them. It is thus possible to apply arbitrary affine transformations to those svps. It is also possible to intersect 2 svps and generate the svp representing the union of these svps...

Finally, it is time for you to render your svps in a pixel buffer. This can be done pretty easily using art_rgb_svp_aa and/or art_rgb_svp_alpha.

All the above steps are summarized in the following diagram: