i'm going to egypt; i'll bring you back something nice
With the help of WebKit developers I finally sorted out the crasher that plagued me over Christmas, and now I see WebKit making network requests, receiving data and calling into the graphics code to get it on screen. The next step is to begin implementing this graphics code.
As far as I can tell I need support for both blitting objects (like images) to the screen, but also need drawing primitives, both simple stuff like lines, circles and rectangles as well as complicated things like BÃ©zier curves and arbitrary paths. It needs to be able to apply a transformation matrix to both paths and images. It needs compositing support. It also needs to be able to operate on screens of arbitrary size and depth.
AROS (and the standard Amiga API) can’t support this. Some of it exists, just not enough.
graphics.library has basic drawing primitives but not advanced stuff like splines and such. Its primitives don’t operate reliably on TrueColor screens, which is what pretty much everything is these days. CyberGraphics provides access to higher-depth modes, but only really for blitting. And we have no support for affine transforms, compositing, or other advanced features.
To Commodore’s credit, its pretty clear that they were moving in this direction. They had these concepts on the market in a time where they were barely even considered elsewhere. I’m quite sure that were they still around today we’d have these features available. Sadly, we don’t, so we must find another way.
I’ve studied the problem in some depth, and I’ve decided to port the cairo graphics library to AROS. Their description sums it up well enough:
The cairo API provides operations similar to the drawing operators of PostScript and PDF. Operations in cairo including stroking and filling cubic BÃ©zier splines, transforming and compositing translucent images, and antialiased text rendering. All drawing operations can be transformed by any affine transformation (scale, rotation, shear, etc.)
A port will be a good thing for everyone. WebKit already has a cairo graphics target, so I’d get my rendering for free. The library is extremely portable, with a great target abstraction. Indeed, I already have the thing compiling and the AROS backend stubbed.
More controversially, I think cairo could actually become the core 2D graphics system for AROS.
graphics.library could be trivially implemented on top of it for compatibility, so there’s nothing to worry about there. We’d implement a cairo backend that talks to a stripped-down version of our graphics HIDD layer (as much of their functionality would no longer be necessary). Once it place it would give easy support for eyecandy like real transparent windows or something like ExposÃ©. Combine that with the plan to get 3D via Gallium, and AROS could become the shiniest thing out there.
My port will be a proper AROS-style shared library,
cairo.library. Cairo’s code is clean enough that I think I can do this without requiring the API to change and while still making it possible to contribute all the changes upstream without adversely affecting them.