| Summary: | cairo_stroke_extends slower when updating from 1.8.8 to 1.10.2 | ||
|---|---|---|---|
| Product: | cairo | Reporter: | Stefan Craciun <scraciun> |
| Component: | general | Assignee: | Carl Worth <cworth> |
| Status: | RESOLVED FIXED | QA Contact: | cairo-bugs mailing list <cairo-bugs> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | 1.10.2 | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Stefan Craciun
2011-05-11 01:41:01 UTC
Which backend are you using? What exactly do you do to see this slowdown? Could you upload a cairo-trace of the problem? How did you determine the mentioned commit? Is it just a guess or did you do a bisect? I am statically linking cairo into my application on windows using pixman. To determine the cause of the performance degradation I profiled the application with cairo 1.8.8 and 1.10.2. It all points to this function: _cairo_path_fixed_stroke_to_traps. I also manually instrumented the code (added clock() calls at the beginning and the end of cairo_stroke_extends). On average, it takes 30 milliseconds with 1.10.2 (across some 400 calls), while with 1.8.8 it never goes above two millis. I don't have a trace file available. If you can tell me how can I get one with this setup (win32 + msvc) I will run the test again and provide the trace. The slowdown may be due to the extra tessellation that was introduced in that commit. For the purposes of extent computation we don't really need to tessellate however, so it might be possible to unregress the extent computation speed without too much trouble. commit af9fbd176b145f042408ef5391eef2a51d7531f8 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sat Jul 30 17:28:21 2011 +0100 Introduce a new compositor architecture |
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.