[cairo] Sorry I broke the text tests! (and status update)
cworth at cworth.org
Mon Feb 19 12:47:04 PST 2007
On Thu, 15 Feb 2007 01:23:03 -0500, Jeff Muizelaar wrote:
> > > The current working version of this lives in the dashing-fixes branch of
> > > git://people.freedesktop.org/~jrmuizel/cairo. It needs a bit more work
> > > before it will be ready to merge upstream.
It actually doesn't live there, (as far as I can tell).
It looks like you've got a repository in the old location that I
originally set up for several committers to cairo. I was able to get
access to it with an ssh-based URL:
and maybe there's a similar git:// URL that would work too.
But I think it would be better to migrate things over to the (now
standard) location for personal git repositories as you mention above.
I can help out in the migration, but I didn't want to move people's
repositories in a way that would break things unexpectedly for them.
> > > 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.
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?
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20070219/b0fcd346/attachment.pgp
More information about the cairo