[cairo] Sorry I broke the text tests! (and status update)
jeff at infidigm.net
Mon Feb 19 13:17:11 PST 2007
On Mon, Feb 19, 2007 at 12:47:04PM -0800, Carl Worth wrote:
> > > > Additionally, I have some rough patches that clean things up even more
> > > > in the dashing-cleanup branch. Assuming the stuff in this branch is
> > > > correct, the dashing code is actually beginning to look better.
> I've just finished up reviewing what was in the dashing-cleanup-4
> branch. The code fixes (and cleanups) look quite good to me---so Jeff,
> I think you'll be able to finish this up and push without any more
> review from me.
Pushed. A big thanks goes to Jeff Smith for making this series of fixes
and cleanups happen.
> Here are the comments I have:
> 1. The 2500-pixel wide image is quite annoying. It's hard to view in
> the results, and it makes the pdiff code (when it fails) _really_
> slow, (as in, over 7 minutes just for this one test).
> Ideally, it'd be nice to just extract the unique things that are
> being tested here and get them expressed explicitly in the much more
> minimal degenerate-path case.
> But if we don't know exactly what the unique things are that this
> test is hitting, then please, can we at the very least eliminate a
> *lot* of the black background pixels that are needlessly slowing
> down the pdiff compare so much?
Done. I cut the image size to about 1/3 of the original.
> 2. The ps result is failing. Part of this looks like a missing
> ps-specific reference image, (differing antialiasing on the
> caps). But part is also the difference in the case of
> to-join-or-not-to-join for a dash that starts precisely at the
> beginning of a "bend" in the path where a join would go.
> I know Jeff has wrestled with this case a bit, as the following
> comment appears in the implementation:
> /* This segment ends on a transition to dash_on, compute a new face
> * and add cap for the begining of the next dash_on step.
> * Note: this will create a degenerate cap if this is not the last line
> * in the path. Whether this behaviour is desirable or not is debatable.
> * On one side these degnerate caps can not be reproduced with regular path stroking.
> * On the other side Acroread 7 also produces the degenerate caps. */
> I'm comfortable with leaving the details of this specific
> situation as backend-dependent in cairo. That is, I'd be fine with
> leaving the implementation as is, (throwing in a ps-specific
> reference image to capture the difference), and not do anything
> heroic like detecting this case and dropping back to image-surface
> fallbacks just to make the PS output match the exact rasterization
> of the image backend.
Done. We have a ps reference image describing the ghostscript
More information about the cairo