Attribute transformations are not handled correctly when rendering about diagrams-cairo HOT 6 CLOSED

(Imported. Original comment by [email protected] on March 31, 2011, 04:08:27 PM UTC)

Still not sure why setting the color causes this bug to show up, but after a bit more playing around I think the problem has to do with freeze.

from diagrams-cairo.

(Imported. Original comment by [email protected] on April 2, 2011, 05:51:35 PM UTC)

I still don't know how to fix this, but I've narrowed the problem down a bit more. The problem seems to be that when rendering a primitive with multiple transformed attributes, the attribute transformations are accumulated rather than being applied separately for each attribute. Concretely,

d # attr1 # ... # attrN # freeze # transform

will have 'transform' applied N times.

I guess we need to somehow group attributes with a common transformation applied to them and do them all at once. It would probably help to retain more structure within a diagram, i.e. have a monoidally-annotated tree rather than immediately flattening everything out into a list of primitives. For example, that way we know that a transformation node applies to everything beneath it; once we flatten the tree out and just have a list of attributes paired with transformations it's impossible to know which transformations "came from the same place" and should hence be grouped and applied only once.

...well, so maybe I do know how to fix it. =)

from diagrams-cairo.

(Imported. Original comment by [email protected] on April 8, 2011, 10:01:13 PM UTC)

I know issue 15 affects this but I'm attaching a patch for educational purposes that addresses this issue.

from diagrams-cairo.

(Imported. Original comment by [email protected] on April 9, 2011, 12:20:28 AM UTC)

Some relevant text from documentation on the cairo website:

"Be careful when trying to draw lines while under transform. Even if you set your line width while the scale factor was 1, the line width setting is always in user-coordinates and isn't modified by setting the scale. While you're operating under a scale, the width of your line is multiplied by that scale. To specify a width of a line in pixels, use cairo_device_to_user_distance() to turn a (1, 1) device-space distance into, for example, a (0.01, 0.01) user-space distance. Note that if your transform deforms the image there isn't necessarily a way to specify a line with a uniform width."

"When you're working under a deforming scale, you may wish to still have line widths that are uniform in device space. For this you should return to a uniform scale before you stroke the path. In the image, the arc on the left is stroked under a deformation, while the arc on the right is stroked under a uniform scale."

from diagrams-cairo.

(Imported. Original comment by [email protected] on April 9, 2011, 12:57:40 AM UTC)

OK, I think I now have a clear idea how to do this. Along each path from a diagram's root to a leaf, we collect up the applied transformations, being sure to keep separate those occurring before and after the innermost call to freeze (see SplitMonoid.hs in core). After drawing the primitive at the leaf (with all the transformations applied to it -- we can either transform the primitive natively and draw it, or apply the transformation in cairo and draw the untransformed primitive, it amounts to the same thing), we apply the portion of the transformation occuring outside the innermost freeze (this is the part that applies to attributes), set all the attributes, and then stroke. (Actually we could also set the attributes, then apply the transformation and stroke. It took me a while to understand that it doesn't matter what transformation is in effect when you set attributes, only what transformation is in effect when you stroke.)

In particular, a transformation should not be stored along with each attribute. This will not work for the reason noted above: the transformation in effect when setting an attribute makes no difference.

from diagrams-cairo.

(Imported. Original comment by [email protected] on April 11, 2011, 12:04:26 AM UTC)

This is now implemented and seems to work correctly in all the examples I've tried so far, and in particular the test cases I developed to figure out what was going wrong before. It turns out that remembering tree structure is actually not necessary to do this correctly -- it would be enough to remember a "split transformation" (i.e. a pair of transformations before/after the innermost freeze) along with each style/primitive pair and apply the frozen portion of the transformation when setting the style attributes and stroking. In fact the current implementation "flattens" the tree into a list of exactly such triples (primitive, split transformation, style) before rendering. But of course remembering the tree structure is nice for other reasons as well.

from diagrams-cairo.