[cairo] cairo/inkscape problems

[Carl Worth]

On Wed, 21 Feb 2007 12:32:58 -0500, Behdad Esfahbod wrote:
> On Wed, 2007-02-21 at 11:39 -0500, bulia byak wrote:
> > 3. This may be related to 2. In a complex drawing with lots of paths,
> > zooming in too closely shows lots of random stray lines all over the
> > screen. Open share/examples/gallardo.svgz from Inkscape distribution,
> > switch to Outline and zoom into an area where many paths are close to
> > each other. At about 5000%, the pandemonium starts.
>
> Yes, both are the same issue, XFAIL test long-lines.

As Behdad mentions, we already have tests in cairo's test suite that
are marked as expected failures for the first two bugs. I'm not sure
about this third one though. I haven't been able to replicate this
third one though. I brought up the SVG file you mentioned and zoomed
in on various parts, but in general they always looked correct. No
evidence of pandemonium.

Could you provide more exact details on how to replicate this? Maybe
even just screenshots before and after the zoom would be enough.

> We may be switching from 16.16 fixed point to 24.8.  That will help here a lot,
> but would not completely fix it.  No idea about the real fix, but it
> shouldn't be that hard.  We just need to detect overflows when
> converting doubles to fixed and act appropriately.  Anyone taking this?

So, currently, you'll run into problems if the device space
coordinates exceed a signed 16-bit integer. And the relatively easy
thing Behdad mentions would push that limit up to a 24-bit integer. I
don't know what limits inkscape would be able to live with.

Other things that could be done include doing some culling of the path
(while still in floating-point) when it exceeds the visible
region. Some things that make this tricky really tricky to do in cairo
are the fact that the line width could be set to something extremely
large after the path is set, so that could change the visibility of
some path components, etc. Another approach would be to save the path
as floating-point inside of cairo, (though that has lots of negative
performance impacts).

Perhaps the right answer is to just do the culling within inkscape
since it already knows things like the stroke width and it already has
floating-point path storage, etc. And the earlier things get thrown
away, the faster they will be all around.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20070221/567ad0c9/attachment.pgp