PDA

View Full Version : Dashed path issues



Ivo Moravec
02-14-2006, 09:12 AM
I was playing around a bit with the reference implementation and was wondering what the correct handling is for Stroked paths when dashing is enabled. An example is:


unsigned char cmds[] = {VG_MOVE_TO_ABS, VG_LINE_TO_ABS, VG_LINE_TO_ABS, VG_CLOSE_PATH};
float pathdata[] = {100,50, 100,150, 200,150};
float dashpattern[] = {100,25,25,25};

The end caps should be set to VG_CAP_SQUARE (and dash phase=0).

At the bottom of the first vertical stroke, the spec is pretty clear that it (the initial vertex) is supposed to be a "JOIN" vertex (p.78-79), but clearly the end cap has been applied in the reference implementation (if the dashing is set such that the final part of the close path line connects to the starting point, the reference implementation creates a JOIN vertex as expected).

The other issue is the top of the first stroke. The first stroke is exactly as long as the dashing phase. What is the correct behavior in this case? The reference implementation first creates the join, then adds the end cap in the direction of the next path element. Or is a 0-length "ON" path supposed to be created at the start of the second line (are 0 length paths ever supposed to be created during dashing?)?

Thanks in advance

Ivo Moravec
02-28-2006, 09:01 AM
Any insights would still be greatly appriciated.

Nils Pipenbrinck
03-03-2006, 06:12 AM
The other issue is the top of the first stroke. The first stroke is exactly as long as the dashing phase. What is the correct behavior in this case? The reference implementation first creates the join, then adds the end cap in the direction of the next path element. Or is a 0-length "ON" path supposed to be created at the start of the second line (are 0 length paths ever supposed to be created during dashing?)?


Hi Ivo,

from my point of view you can't really define a correct behavior in this case. The exact length of a line segment can't be really calculated using floating point arithmetic. There are always some rounding errors, order of instructions and optimization-options involved.

It may be very likely that the reference code calculates a line length of 100 + (some very very small number) and correctly decided that a join + end-cap is required in this case.

Maybe it would be a good idea to eliminate path segments with a length less than the expected roundoff error range after dashing to avoid such inconsistencies.

(but that's just my personal opinion)
Nils Pipenbrinck

Ivo Moravec
03-03-2006, 11:49 AM
That makes sense.

Thank you.