[cairo] Re: [Inkscape-devel] NEW: cairo rendering in outline mode

[bulia byak]

Last night, with the help of Carl Worth, the issue of cairo/inkscape
not working on mac was more or less clarified. Here's how I understand
it.

When drawing into a memory buffer, cairo uses a fixed byte order of
the R, G, B, A bytes regardless of the platform.

Inkscape and GDK (which is used by Inkscape for drawing to screen),
however, both use system-dependent byte order, i.e. the order of R, G,
B, A is determined by the hardware and is different on PC and Mac
platforms.

And it so happens that the fixed order of cairo coincides with the
hardware order on PC but not on Mac. Hence, painting by cairo directly
into Inkscape/GDK buffers worked on PC but on Mac, all colors are
wrong and (in case of outline) black color gets zero opacity, i.e.
becomes invisible.

Essentially, this means that Inkscape and cairo are not compatible as
is, and that a gradual switching of parts of our display engine to
cairo is not possible. (Unless we ditch Macs, of course.)

Even if we switch our screen output from using GDK to cairo (which is
relatively easy), this won't help - it will just break rendering on
PCs too. Inkscape has a lot (and I do mean A LOT) of code that assumes
system-dependent byte order. Composers, decomposers, premultipliers,
unpremultipliers, blitters and blotters of all sizes and colors
permeate the codebase. Most of them come all the way from Sodipodi.

Now, of course, it's possible to create "adapters" for cairo bits.
That is, every time we use cairo, instead of drawing directly into
Inkscape buffer, we can draw into a temporary buffer instead,
rearrange the bytes in that buffer, and then compose that into the
main buffer. But that is certain to more than negate the feeble speed
gains we're seeing from cairo's image backend rendering.

Or, we can attempt a much more drastic rearchitecturing, by changing
our functions so they pass around cairo contexts instead of Inkscape
buffers. With this approach, byte reordering will be needed less
frequently, and eventually eliminated completely. But this is not only
much more work, it will also mean a lot more bugs and regressions and
quite some time before Inkscape is usable again.

So, it looks like due to this stupid byte-order issue, cairo for us is
practically an all-or-nothing proposition - and much more hassle than
I expected. I'm not saying it's impossible but it is quite a major
project that cannot be done gradually.

Unless, of course, cairo gets so in love with Inkscape as to provide
us with a new image surface with system-dependent byte order...

> > > On 2/24/07, jiho <jo.irisson at gmail.com> wrote:
> > >> I have compiled SVN for the first time since 0.45 today and there
> > >> appear to be a problem with this new outline mode: nothing is visible
> > >> in outline mode, tough objects are still selectable.
> > >> This is with cairo @1.2.6, gtk2 @2.10.9 on Mac OS X.

-- 
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org