Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[encoding] Bump estimate for segments #454

Merged
merged 1 commit into from
Mar 15, 2024
Merged

Commits on Mar 14, 2024

  1. [encoding] Bump buffer estimation for segments

    The segments (and segment counts) buffers contain intermediate data
    structures that associate lines (post-flatten, post-binning) with tiles.
    Their overall count depends on the number tile crossings for each line.
    
    These counts are now estimated as follows:
    
    1. Explict lines with known endpoints are estimated precisely by
       guessing the worst case rasterization of the hypothenuse (i.e. the
       sum of the tiling estimate for the x and y coordinates.
    
    2. Explicit lines with unknown endpoints (e.g. the caps on a stroke)
       are estimated based on the length of the segment.
    
    3. Flattened curves are estimated by tiling a line whose length is
       derived based on a conservative estimate of the curve's arc length.
       The segment count is forced to be at least as large as the Wang's
       estimate used for the LineSoup count.
    
    This implementation currently has two major shortcomings:
    
    I. Clipping is not taken into account, so the count is overstimated when
       layers are present or when geometry lies outside the viewport. There
       are ways to address this but they will require some changes:
    
       a) Most of the count accummulation happens at encode time but the
          bounds of the viewport are only known at render time. This could
          be changed so that most of the accummulation happens at render
          time and additional data (like the bounding box of each shape) get
          tracked during encoding.
    
       b) It might make sense to track the clip stack to test each shape's
          bounding box against the clip geometry while resolving the counts
          and use that as input to a heuristic. It is also possible to
          discard shapes that lie completely outside the bounds of the clip
          geometry. All of this would require additional tracking that
          impacts CPU time and memory usage.
    
    II. A rotation that is present in the transform has an impact on tile
        crossings. We can precisely account for this for explicit lines with
        known endpoints but we have to use a heuristic for curves. The
        estimator doesn't track detailed shape data, so a heuristic must be
        used when appending a scene fragment. We currently inflate all
        segment counts as if they have a 90 degree rotation whenever a
        transform should apply.
    
    Overall the segment count tends to be overestimated 3x-10x. There is one
    known failure mode when the count is underestimated with _very_ small
    scale factors ("conflation artifacts" test scene).
    armansito committed Mar 14, 2024
    Configuration menu
    Copy the full SHA
    c4e60dc View commit details
    Browse the repository at this point in the history