[Kde-graphics-devel] Status update

[Dirk Schönberger]

> I also got the recent Qt beta. Seems pretty cool. I don't know if I will
be
> able to use Arthur for painting to images, tho. Too many things use
pixmaps,
> most notably brushes. This would make an image backend, something I want
to
> eventually do, inefficent (lots of pixmap<->image conversion).

You could implement an own paint engine for Arthur which works on a QImage /
memory buffer.
I think you really need the QPixmaps for e.g. brushes, because they are
separate data from the actual render target.

You can find another attempt for a rendering API based on QPainter in my
KPainter API in kdenonbeta.
This already contains a buffer / libart based backend and a backend which
uses QPainter.
Other interesting backends would include a Arthur based backend or a Cairo
based backend.

My API doesn't use so much QPixmaps, instead it uses a more "declarative"
approach to e.g. describing gradients.

> We do have a couple libart-based painting classes, mostly for the SVG
> applications. It would be interesting to look into doing a more complete
one
> with all of Arthur's features, (coordinate transformations, paths,
etc...).
> If I did this it would probably work on both QImage and MImage.

KPainter is similar to the Karbon 14 rendering engine, but it provides
multiple possible backends.
The other attempts I have seen are mostly directly coupled to a lowlevel
rendering library like AGG or libart.

Regards
Dirk