[cairo] [PATCH 0/5] Fix dashing with zero length dash intervals.

Carl Worth cworth at cworth.org
Thu Apr 13 22:42:31 PDT 2006


On Fri, 14 Apr 2006 00:50:38 -0400, Jeff Muizelaar wrote:
>
> The accuracy improvements do not seem to have an effect on any of the
> test suite images.

Well that makes things nice and easy.

> There is a fundamental difference between adding the caps to zero-length
> segments vs. zero-length paths: zero-length paths have no slope whereas
> zero-length segments do because they sit on a nonzero-length line.

OK. I'll withdraw my insistence on fixing the other issue at the same
time.

> I have something like this sitting on the 'dashing' branch in my public
> repository. I added the test case at the begining of the entire patchset.
> The results will be meaningless up to patch #3. After patch #3 the
> results are correct except for the issue addressed in patch #4.

That's a very lovely patch sequence. Please feel free to push it.

> What this means visually is that the with the first dash array the line
> will start with a capped line at the begining. As the value of third
> element in the array decreases the caps get closer and closer
> together and one would expect that we would eventually just be left with
> the caps.  However, with the current code when the 3rd element of the
> array reaches 0.0 the cap disapears because it is skipped over.

Thanks for the careful explanation. That helps slow people like me.

The argument above is fairly compelling. With cairo we try to avoid the
situation that a small changes in user input lead to a big change in
the graphical result. And the disappearance of a dash segment like
this seems worth avoiding if possible.

(Though I guess that a small change in the dash offset can still make
an initial zero-length segment disappear in a similar way, right? Oh
well, there's not much we can do about that I suppose.)

But anyway, this seems worth doing---particularly as you've already
done the work and written it up so well.

>         Overall, finding a clean and clear way to address this issue
> has been a bit of a challenge and I'd welcome suggestions for ways to
> improve it.

I'd still prefer to avoid equality checks against floating-point
values. How about this instead (as I just mentioned in IRC):

	/* We stop searching for a starting point as soon as the
	   offset reaches zero.  Otherwise when an initial dash
	   segment shrinks to zero it will be skipped over. */
	while (offset > 0.0 && offset >= stroker->style->dash[i]) {
	...
	}

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060413/796745ab/attachment.pgp


More information about the cairo mailing list