You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Creation of ScanEdgeCollection can take up to ~7% according to profiler results, so this seems to be a reasonable optimization. Instances shall be keyed by subsampling since y values in ScanEdge-s are rounded to subpixel scanlines.
Most (all?) IPath implementations cache their tessellation data as an InternalPath member. Whenever we render an IPath (InternalPath) with a given subsampling, we first convert the InternalPath to a TessellatedMultipolygon (which is just a more efficient storage for the points in InternalPath), then create a ScanEdgeCollection which is a data structure that already depends on the value of subsampling.
Assuming it's a common use case to render an IPath multiple times (which might be a wrong assumption! ... we should analyze use-cases), we could create a cache of ScanEdgeCollections inside InternalPath, so we don't need to recreate it on each render run. Since ScanEdgeCollection depends on subsampling, we should cache (int, ScanEdgeCollection) pairs. In fact one pair should be enough, since we don't expect users to switch the subsampling ratio between render runs.
Creation of
ScanEdgeCollection
can take up to ~7% according to profiler results, so this seems to be a reasonable optimization. Instances shall be keyed bysubsampling
since y values inScanEdge
-s are rounded to subpixel scanlines.Related: #103
The text was updated successfully, but these errors were encountered: