KevLinDev Blog

The current Longhorn documentation does not indicate what happens when a StrokeDashArray has an odd number of entries. It seems the typical solution is to repeat all entries once to end up with an even number of entries. For example, this is what the SVG specification indicates to do in that case and after a few tests in LH4074, it appears this is the case in Avalon too. However, I noticed that StrokeDashArray properties that contain only one number result in no stroke being display. If I repeat the number, then the stroke appears as expected. So, I’m not sure if this is a bug, but at the very least, the behavior is inconsistent.

I was glad to see StrokeDashArray (and other stroke-related properties) implemented in Longhorn, Build 4074. However, I think there is a bug in that mechanism that is causing the individual dashes within the stroke to be too large. For example, I’m using the following markup:

<Line xmlns="http://schemas.microsoft.com/2003/xaml"
    X1="155" Y1="111" X2="465" Y2="111"
    Stroke="Black" StrokeThickness="10"
    StrokeDashArray="2 2 1 1"/>

I expect the pixel length shown in the following image to be 60 pixels: 20 pixels on, 20 pixels off, 10 pixels on, 10 pixels off (20+20+10+10 = 60). However, as can be seen from the antialiasing in the image, we are getting (roughly) 20.5 (20 + 0.5), 20.9 (0.5 + 20 + 0.4), 10.1 (0.6 + 9 + 0.5), and 10.5 (0.5 + 10) for a total of 62 pixels.

I noticed that LineGeometries do not render in GeometryCollections with more than one Geometry. For instance, with the following markup

<Canvas xmlns="http://schemas.microsoft.com/2003/xaml">
    <Path Fill="Blue" Stroke="Black" StrokeThickness="5">
        <Path.Data>
            <GeometryCollection>
                <LineGeometry
                    StartPoint="50,50" EndPoint="300,50"/>
                <EllipseGeometry
                    Center="175,175" RadiusX="50" RadiusY="50"/>
            </GeometryCollection>
        </Path.Data>
    </Path>
</Canvas>

I expected to see a line and an ellipse, as seen here

However, as shown in this next image, only the EllipseGeometry appeared.

And, just to make sure LineGeometries do render, I commented out the EllipseGeometry from the preceding markup and the line appeared as expected.