From: MenTaLguY [mailto:mental@...3...] Sent: 14 October 2005 21:49
So why doesn't someone do a sort of Ultra-draw wrapper super-API
library
thing that we can both use. i.e. it provide one super-set rendering
API
that itself calls down to XaraDraw, Cairo, Quartz depending on user
or
program preferences. And then we'd both use this ultra-draw and both gain the desired benefits. Quartz, Cairo and XaraDraw are similar
enough
to make this not too huge a job I would guess.
I would be reluctant to introduce yet another new API. I've been peripherally involved in the Cairo effort, and have learned that good API design is VERY hard in this area.
Well yes, you're right the last thing anyone needs I more APIs, but on the other hand Cairo has a pretty limited feature set (but on the positive side, seems super-clean, very simple and that's worth a great deal.)
However, I suspect XaraDraw doesn't owe its speed so much to the specific rasterization backend as to a "retained-mode" layer which can do caching and optimization of drawing calls?
Almost a great deal of the speed of Xara X1 and predecessors is the rasterizer backend (but the main object tree is designed around calling this efficiently). In Xtreme we added a bitmap caching layer which can make substantial further speed-up for groups, layers, shadows, feathered stuff, blends, etc, which otherwise an be relatively slow to render.
Cairo pretty much only does rasterization; it provides no
retained-mode
layer of its own.
There seems a very close correspondence between it and XaraDraw, and Quartz (and GDI+ even). These all are all non-retained rastersization engines.
My own feeling is that it would be most beneficial to take Xara's retained-mode layer, target it to Cairo, and then write a new Cairo backend using XaraDraw's lower-level layers (in the long-term, we
would
also want to investigate merging what we could of the "XaraDraw" Cairo backend into Cairo's normal software backend, assuming you folks were comfortable with relicensing those bits accordingly).
Yes I think there's a lot of sense in that approach. Trouble is we might not have a clear, retained-mode layer as you put it. You can see once the source code is provided. The 'viewer' that forms the core of the download we now have is probably close to this.
In case Cairo's generic API proved insufficiently rich for everything required by Xara, note that Cairo does allow for backend-specific API extensions. We could simply employ those in the short-term, and it is likely that many could be incorporated into the generic API over time.
Ah, OK, that is useful. Cairo certainly is not rich enough and appears to implement a relatively small percentage of the capabilities of the XaraDraw engine, and is rather less capable than the Quartz PDF engine even. But if it's an extendable API that may be the best way to go. There might be licensing issues, would need to be looked at.
Both Inkscape and Xara could then use Xara's retained-mode layer, and both could use Cairo underneath while still taking advantage of Xara's optimized rasterization routines. In the long run all Cairo-based applications (e.g. all GTK and wxGTK applications) would potentially benefit, and Xara could benefit from future third-party improvements
to
Cairo directly.
That approach would let us stick with two already well-refined APIs,
and
take advantage of the principle that a rising tide lifts all boats.
Yep, a lot of merit to that approach.
Charles