)]}'
{
  "commit": "c4e60dcf32dbf904303caa83bc4d638f5050a1e8",
  "tree": "6131e59aec326b9dc07aaf284e0eca57364f75b2",
  "parents": [
    "2fb6a37357551e77c5c0646bfc3c9b20dd79acac"
  ],
  "author": {
    "name": "Arman Uguray",
    "email": "armansito@google.com",
    "time": "Tue Feb 20 13:58:33 2024 -0800"
  },
  "committer": {
    "name": "Arman Uguray",
    "email": "armansito@google.com",
    "time": "Thu Mar 14 15:41:47 2024 -0700"
  },
  "message": "[encoding] Bump buffer estimation for segments\n\nThe segments (and segment counts) buffers contain intermediate data\nstructures that associate lines (post-flatten, post-binning) with tiles.\nTheir overall count depends on the number tile crossings for each line.\n\nThese counts are now estimated as follows:\n\n1. Explict lines with known endpoints are estimated precisely by\n   guessing the worst case rasterization of the hypothenuse (i.e. the\n   sum of the tiling estimate for the x and y coordinates.\n\n2. Explicit lines with unknown endpoints (e.g. the caps on a stroke)\n   are estimated based on the length of the segment.\n\n3. Flattened curves are estimated by tiling a line whose length is\n   derived based on a conservative estimate of the curve\u0027s arc length.\n   The segment count is forced to be at least as large as the Wang\u0027s\n   estimate used for the LineSoup count.\n\nThis implementation currently has two major shortcomings:\n\nI. Clipping is not taken into account, so the count is overstimated when\n   layers are present or when geometry lies outside the viewport. There\n   are ways to address this but they will require some changes:\n\n   a) Most of the count accummulation happens at encode time but the\n      bounds of the viewport are only known at render time. This could\n      be changed so that most of the accummulation happens at render\n      time and additional data (like the bounding box of each shape) get\n      tracked during encoding.\n\n   b) It might make sense to track the clip stack to test each shape\u0027s\n      bounding box against the clip geometry while resolving the counts\n      and use that as input to a heuristic. It is also possible to\n      discard shapes that lie completely outside the bounds of the clip\n      geometry. All of this would require additional tracking that\n      impacts CPU time and memory usage.\n\nII. A rotation that is present in the transform has an impact on tile\n    crossings. We can precisely account for this for explicit lines with\n    known endpoints but we have to use a heuristic for curves. The\n    estimator doesn\u0027t track detailed shape data, so a heuristic must be\n    used when appending a scene fragment. We currently inflate all\n    segment counts as if they have a 90 degree rotation whenever a\n    transform should apply.\n\nOverall the segment count tends to be overestimated 3x-10x. There is one\nknown failure mode when the count is underestimated with _very_ small\nscale factors (\"conflation artifacts\" test scene).\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "29dc31bf6bcf4610b9d73693be919387bde9691c",
      "old_mode": 33188,
      "old_path": "crates/encoding/src/estimate.rs",
      "new_id": "086cfa4a2c1e63c61425266de0335abd42da69fc",
      "new_mode": 33188,
      "new_path": "crates/encoding/src/estimate.rs"
    }
  ]
}