Improve area pattern performance

[pmconne]

Is your feature request related to a problem? Please describe. Framerate can plummet when displaying patterned areas with highly-detailed boundary curves. The backend instances all of the pattern symbols and produces a boundary ClipVector to be applied to those symbols at display time. The more complicated/detailed the boundary, the more clip planes are produced, and the more work the fragment shader must do to clip the symbols.

Describe the solution you'd like Framerate remains acceptable when displaying complex patterned areas. A variety of options can be considered, possibly in combination:

• Don't instance the symbols - instead do what we used to do and stroke each symbol. (We stopped doing that because it produced gigantic tiles).
  • Consider stroking symbols only if boundary is "too complex"?
  • Consider instancing all the unclipped symbols, and stroking only the symbols that intersect the boundary?
• Produce two sets of instances: those that intersect the boundary so must have the clip applied at display time, and those which don't intersect the boundary and can be displayed with no clip.
• ClipStack should block-copy data in recomputeTexture instead of copying it byte-by-byte.
  • This has been confirmed to double FPS, even when not bothering to check if data actually changed.
  • But time spent recomputing texture pales compared to fragment shader time.
• If the boundary intersects tile boundaries, the backend appends a cuboid clip to the ClipVector. Consider:
  • Prepending it instead, so the shader can exit early for symbols outside of the tile; or
  • Clipping the boundary on the backend to omit portions of the boundary outside of the tile, reducing the number of clip planes.
• If backend produces "too many" clip planes, reduce chord tolerance and compute lower-resolution clip boundary?
• Optimize clipping shader somehow?
• Render patterns as textures?
• Improve convex decomposition (in user data set, we end up with a convex set of 3 planes per triangle in the clip boundary, but it is plain to see more efficient decompositions are possible).
• Other ideas?

Describe alternatives you've considered See above.

Additional context This issue is affecting a user. Contact me for further information.

[pmconne]

Example - all .txt files contain JSON (github disallows JSON attachments). Clip boundary . ClipVector produced in native code from clip boundary using chord tolerance of 1.4051897015886328. Union of convex clip plane sets produced on frontend from ClipVector.

This is what the boundary looks like:

[pmconne]

This is on hold while product management attempts to convince the user to use materials or fill instead of area patterns.