Bug 38079 - Multi-component path containing curve_to is not drawn completely
Summary: Multi-component path containing curve_to is not drawn completely
Status: RESOLVED FIXED
Alias: None
Product: cairo
Classification: Unclassified
Component: general (show other bugs)
Version: 1.10.2
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Andrea Canciani
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-08 08:40 UTC by Martin Simmons
Modified: 2011-06-09 04:37 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Example source code (2.58 KB, text/x-csrc)
2011-06-08 08:42 UTC, Martin Simmons
Details
Bugfix (workaround?) (3.17 KB, patch)
2011-06-09 01:54 UTC, Andrea Canciani
Details | Splinter Review

Description Martin Simmons 2011-06-08 08:40:35 UTC
Certain paths containing multiple move_to and curve_to elements are drawn incorrectly in 1.10.2.  I've reproduced this with the attached example cairo-arc.c on Fedora 14 x86_64 using the cairo tarballs and Fedora's pixman 0.18.4.

The example draws three curves in black as a single path and the same three curves in red as three separate paths 10 pixels to the right.  They should be identical in all other ways, but the black curve at the top is about 20 pixels shorter than the red curve in 1.10.2.

The debugging function print_path in the example also shows that the path extent of the black curves doesn't cover the path elements (y1 should be -136.601562):

version 1.10.2
path extents = -100.000000 -100.000000 100.000000 100.000000
path elements(18):
  move_to 100.000000 100.000000
  curve_to 44.773438 100.000000 0.000000 55.226562 0.000000 0.000000
  move_to -100.000000 -100.000000
  curve_to -44.773438 -100.000000 0.000000 -55.226562 0.000000 0.000000
  move_to 36.601562 -136.601562
  curve_to 64.214844 -88.773438 47.828125 -27.613281 0.000000 0.000000

Here is the corresponding output in 1.8.8, where it draws as expected:

version 1.8.8
path extents = -100.000000 -136.601562 100.000000 100.000000
path elements(18):
  move_to 100.000000 100.000000
  curve_to 44.773438 100.000000 0.000000 55.226562 0.000000 0.000000
  move_to -100.000000 -100.000000
  curve_to -44.773438 -100.000000 0.000000 -55.226562 0.000000 0.000000
  move_to 36.601562 -136.601562
  curve_to 64.214844 -88.773438 47.828125 -27.613281 0.000000 0.000000
Comment 1 Martin Simmons 2011-06-08 08:42:13 UTC
Created attachment 47720 [details]
Example source code
Comment 2 Andrea Canciani 2011-06-09 01:18:18 UTC
This seems to be fixed (along with other path construction bugs) in master.
Can you check and reopen if you manage to reproduce it?
Comment 3 Andrea Canciani 2011-06-09 01:54:06 UTC
Created attachment 47761 [details] [review]
Bugfix (workaround?)

I managed to create a simple patch which is unlikely to cause big regressions in 1.10, so (after appropriate testing etc etc) it might be merged.

While doing so, I realized that both 1.10 and master actually have some defects regarding extents computation (basically stroke_extents and fill_extents cannot be computed in the same way).
I'll try to extend get-path-extents to show these issues.
Comment 4 Martin Simmons 2011-06-09 04:37:58 UTC
Thanks, your patch fixes the problem for me and I've not yet noticed any other problems while using it.


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.