We've noted before in principle that the Stroker in Marlin and Pisces both compute widened geometry for the entire path even if parts of it are so far outside the clip that they cannot affect rendering.
Recently someone filedJDK-8183530 which demonstrates a real performance issue for AreaChart instances that have a huge list of data that is much wider than the graphed portion. Technically it is an issue that the AreaChart object maintains such huge path objects in the first place and it should subset the data to the visible portion when creating the Path objects to represent the chart, but it points out that the issue of time spent widening non-visible parts of a path is more than just a theoretical problem.
SeeJDK-8183530 for a test case, though a standalone that just tests out-of-range stroking would be trivial to write.
Recently someone filed
See
- duplicates
-
JDK-8160600 Inadequate performance when rendering dashed stroke
-
- Closed
-
- is blocked by
-
JDK-8191814 Marlin rasterizer spends time computing geometry for stroked segments that do not intersect the clip
-
- Resolved
-
- relates to
-
JDK-8183530 JavaFX charts peg rendering thread as more data is added
-
- Resolved
-
-
JDK-8160600 Inadequate performance when rendering dashed stroke
-
- Closed
-