I wanted to add a rotation test to the zero-length line unit test but I ran into an interesting problem with the tesselation. The following patch fails to render the "rotated" versions of the line/path, but if you change the rotation to any value except for 45, then it renders just fine. Why does a 45 degree angle freak out the tesselator? @bdero ?

diff --git a/impeller/display_list/display_list_unittests.cc b/impeller/display_list/display_list_unittests.cc
index 08e4bb352d..5ee7f7b409 100644
--- a/impeller/display_list/display_list_unittests.cc
+++ b/impeller/display_list/display_list_unittests.cc
@@ -488,6 +488,13 @@ TEST_P(DisplayListTest, CanDrawZeroLengthLine) {
     paint.setStrokeCap(cap);
     builder.drawLine({50, 50}, {50, 50}, paint);
     builder.drawPath(path, paint);
+    builder.save();
+    builder.translate(300, 50);
+    builder.rotate(45);
+    builder.translate(-50, -50);
+    builder.drawLine({50, 50}, {50, 50}, paint);
+    builder.drawPath(path, paint);
+    builder.restore();
     builder.translate(0, 150);
   }
   ASSERT_TRUE(OpenPlaygroundHere(builder.Build()));

Tried this patch locally and the frame fails to render for me.

Stepped through with the debugger and it's hitting the polyline point size check. One approach that can work is to embrace the deduplication and handle the single point contour case internally like this:

diff --git a/impeller/entity/contents/solid_stroke_contents.cc b/impeller/entity/contents/solid_stroke_contents.cc
index c332b966c5..fecb17798c 100644
--- a/impeller/entity/contents/solid_stroke_contents.cc
+++ b/impeller/entity/contents/solid_stroke_contents.cc
@@ -72,7 +72,7 @@ static VertexBuffer CreateSolidStrokeVertices(
   VertexBufferBuilder<VS::PerVertexData> vtx_builder;
   auto polyline = path.CreatePolyline();

-  if (polyline.points.size() < 2) {
+  if (polyline.points.empty()) {
     return {};  // Nothing to render.
   }

@@ -95,6 +95,12 @@ static VertexBuffer CreateSolidStrokeVertices(
     std::tie(contour_start_point_i, contour_end_point_i) =
         polyline.GetContourPointBounds(contour_i);

+    if (contour_end_point_i - contour_start_point_i == 1) {
+      cap_proc(vtx_builder, polyline.points[0], {0, 1}, smoothing);
+      cap_proc(vtx_builder, polyline.points[0], {0, -1}, smoothing);
+      continue;
+    }
+
     if (contour_end_point_i - contour_start_point_i < 2) {
       continue;  // This contour has no renderable content.
     }

These normals aren't respecting the transform, but that's a separate issue.

These normals aren't respecting the transform, but that's a separate issue.

AFAICT this method works entirely in path-space? The normals aren't necessarily normal in a transformed space. (Which means everywhere it does a {-y, x} or something similar to the normals would not work in device space under a skew transform.)

Sorry, disregard the comment about the normals -- I think I misread the test. I suspected we weren't handling normals right in the vertex shader, but it lgtm.