The Cairo 2D graphics library is now available on AmigaOS due to the efforts of programmer Andrea Palmaté. He also ported LibXML2 and Libfreetype. LibXML2 is the XML C parser and toolkit of GNOME. All ports are available here.
The Cairo 2D graphics library is now available on AmigaOS due to the efforts of programmer Andrea Palmaté. He also ported LibXML2 and Libfreetype. LibXML2 is the XML C parser and toolkit of GNOME. All ports are available here.
I wonder how sucessful Cairo can be… (when talking about cross-plataform…)
If it can archive good stability AND performance in Windows, Mac and Linux (maybe Amiga, SkyOS and others too), it’ll become a great drawing option for developers, and also bringing a lot of improviment for software that depends on it (like GTK+ now).
As Firefox developers are also embracing Cairo, as long the optimizations for drawing in each plataform (like using hardware/native drawing in Windows and MacOS X), Cairo has potention for a very bright future (at least, I hope so)…
wonder how sucessful Cairo can be… (when talking about cross-plataform…)
It could be successful, the API is great and the results look excellent.
It has the problem that it very targeted at XRender, using XRender’s trapezoid primitives as its own and using Port Duff composition which neither Quartz nor Win32 have API level access too, so it’ll draw at a lower level on Linux that everything else, glitz backend excepted. The OSX backend for example is a ‘draw using software to a bitmap then blit’ hack. On the win32 back a curve, for example, is converted to trapezoids which get converted to ‘Polygon’ API calls which then get
split into whatever the low level primitive win32 uses to rasterize.
It’s the GDK story all over again where for any port 90% of the work is ‘fake the way X11 works’ 🙂
Riiight…
That’s like saying PDF/OpenGL/Postscript is only targeted at <stuff it works on>. Cairo does _not_ make the same misstake as GDK did.
Sure, a lot of the backends need improving but that will happen in due time.
That’s like saying PDF/OpenGL/Postscript is only targeted at <stuff it works on>
No its not. the fact that you had to use <stuff it works on> shows that there’s no real comparison. PDF, OpenGL and Postscript are at the cairo frontend level, they are basically a lit of commands, move here, draw a line to there, use these coordinates for a Vertex. Cairo goes further by saying how these lines should be drawn using what ends up as a thin wrapper around XRender the same way that GDK 0.1 – 2.8.x were thin wrappers around X11. Oooops. that mistake you said they won’t make, to late already have.
On Linux cairo goes
cairo-> tessellation -> XRender
OSX would have to go, given a proper backend.
cairo->tessellation->quartz drawns trapezoids->decompose to primitives -> compositor.
By having the tessellation as part of the cario front end instead of the backend they’ve doomed every other backend bar glitz not being the very poor relative. Proper OSX and win32 end up decomposing the graphics twice Glitz only works well because the trapezoids can be represented easily as a quad. but that means you’ve got a GL context not a CGContext or a Win32 context . Quartz2d and Avalon or whatever it’s called now could well be better off with a wrapper rather than a backend.
The current backend mechanism is _not_ set in stone.
If you read this
http://lists.freedesktop.org/archives/cairo-announce/2005-August/00…
you will see that while the API is frozen for this release many of the backend work is considered experimental and there is more work needed on it. It is too early to form opinions
If any of these does require a API change a new parallely installable major version would be releases similar to GTK 1.x and 2.x series.
They would have to totally change the backend API to make OSX and Win32 backends efficient. The graphics have already been tesselated by the time they are passed over to the backend. Here’s the quartz how the API to the quartz backend to show where the API lays
static const struct _cairo_surface_backend cairo_quartz_surface_backend = {
NULL, /* create_similar */
_cairo_quartz_surface_finish,
_cairo_quartz_surface_acquire_source_image,
NULL, /* release_source_image */
_cairo_quartz_surface_acquire_dest_image,
_cairo_quartz_surface_release_dest_image,
NULL, /* clone_similar */
NULL, /* composite */
NULL, /* fill_rectangles */
NULL, /* composite_trapezoids */
NULL, /* copy_page */
NULL, /* show_page */
_cairo_quartz_surface_set_clip_region,
NULL, /* intersect_clip_path */
_cairo_quartz_surface_get_extents,
NULL /* show_glyphs */
};
Its not at line_to, curve_to level but much lower and very much tied to XRender.
Since everyone else is preoccupied proclaiming to have the solution to the countless flaws in WindowServer design I thought I’d address the topic and pass on congratulations.
How long before we see the boing ball using Cairo?
I think the (near) future is going towards hardware acceleration, and research must be done in this field. In this context i think that Cairo backends system couldn’t be a good solution, due to its requirement to be a compatible backend at the same level of other backends.
An “a priori” vertical analisys could bring to the right way for accelerated vector graphics render.
For one of my projects, I have had a look at open source vector graphics libraries out on the net. Beside Cairo+glitz i’ve found svgl toolkit, Agile2D and Amanith framework.
Svgl unfortunately is not maintained anymore, it does not stroke joins particularly cleverly, but it has a good interesting accelerated rendering approach and pipeline.
Amanith is the more promising one, from my point of view. It compiles without problems on several differents architectures and it’s oriented towards hardware rendering (from my tests this library produce the lesser number of line segments during curves flattening); it’s a pity that it lacks a full svg-style rendering layer. But the authors have ensured me that they are still working on it.
The API is very clear and complete, ansi c++ and it has also some usefull modeling functions.