Bug 56099 - path rendering problems in 1.12.4
Summary: path rendering problems in 1.12.4
Status: RESOLVED FIXED
Alias: None
Product: cairo
Classification: Unclassified
Component: general (show other bugs)
Version: 1.12.4
Hardware: Other All
: medium normal
Assignee: Carl Worth
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-17 18:19 UTC by Jakub Steiner
Modified: 2013-08-21 13:21 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Jakub Steiner 2012-10-17 18:19:24 UTC
When talking to Inkscape folks as to why the outline in Inkscape 0.48.3 doesn't work anymore in Fedora 18 (no paths are rendered at all), I was pointed to cairo 1.12.4 hinting this change might be the culprit:

http://lists.cairographics.org/archives/cairo/2012-September/023532.html
Comment 1 Chris Wilson 2012-10-17 22:01:07 UTC
No, that commit is not responsible afaict.
Comment 2 Chris Wilson 2012-10-17 22:31:20 UTC
bdf83008f4b2c723fd8e65e2a92bc47a2e7bc442 is the first bad commit
commit bdf83008f4b2c723fd8e65e2a92bc47a2e7bc442
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sat Aug 25 08:39:30 2012 +0100

    compositor: Skip invisible strokes
    
    If the pen is reduced to a single point, it is effectively invisible
    when rasterised, so skip the stroke composition.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Comment 3 Chris Wilson 2012-10-17 22:43:28 UTC
inkscape sets the geometric tolerance to 1.25 *pixels* for its half-pixel wide strokes which means that the stroke is being treated as invisible since both edges can be treated as coincident.
Comment 4 Chris Wilson 2012-10-21 16:36:59 UTC
Fundamentally I think this is an Inkscape bug, but obviously I can't allow such a regression in a stable series:

commit c565bad8901dbe66e1402cdc2418986e96e698e3
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Oct 19 12:22:58 2012 +0100

    pen: Relax invisibility criteria from half-tolerance to quarter-tolerance
    
    Inkscape is one user who sets geometric tolerance to 1.25 pixels when
    stroking sub-pixel lines. Whilst we wait for inkscape to set sensible
    values for their tolerance, we have to allow through the current values
    in order to prevent the fine strokes from disappearing.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56099
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Comment 5 ~suv 2012-10-22 20:45:48 UTC
AFAICT outline view mode is still broken with cairo 1.12.6 and Inkscape 0.48.3.1 (stable release) / current trunk (r11821).

Could you explain what "sensible values for their tolerance" would be (for optimal performance) so that a bug for inkscape can be filed, or the developers be notified on the mailing list?

Tests with modified tolerance value in current trunk [1] give me these results:
- cairo 1.12.2: path outlines are visible with current value (1.25)
- cairo 1.12 4: path outlines are visible with ct.setTolerance <= 0.49
- cairo 1.12.6: path outlines are visible with ct.setTolerance <= 0.99

The tests have been done on OS X 10.7.4 with Inkscape 0.48+devel r11821:
for cairo 1.12.4: only with inkscape builds using the Quartz backend (GTK2, cairo, pango) - my current X server is not recent enough to be compatible with cairo 1.12.4.
for cairo 1.12.6: tests done with inkscape builds using either backend (X11, Quartz)


[1] <http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/src/display/drawing-shape.cpp#L160>
Comment 6 ~suv 2012-11-06 19:36:19 UTC
> outline view mode is still broken (…)

Tracked for Inkscape in 
<https://bugs.launchpad.net/inkscape/+bug/1074612>

Fix for outline view mode committed to Inkscape trunk:
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/11862>
Backported to Inkscape stable (for 0.48.4):
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/RELEASE_0_48_BRANCH/revision/9918>


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.