Matej Knopp

> The Path object lifecycle is tied to the display list that used it, so it should persist across frame as long as the pictures are stable : #50076 ....

I'm not opposed to caching the tesselation data, just trying to make sure I understand what the implications are. For example I think this will drastically improve `static_path_tesselation` macrobenchmark, but...

> The animated tessellation benchmark already covers this case. Looking at code, this is what happens in the painter: ```dart class _CameraIconPainter extends CustomPainter { @override void paint(Canvas canvas, Size...

> I don't think we're going to ever do content based hashing of paths as that would pretty expensive, especially for large animated paths which we already suffer with. So...

I agree with @flar here. This seems like a result of not being aware of physical pixels on framework level. Personally I'm pixel snapping all my applications, even wrote a...

Another thing to consider would be a `DlRegion` that uses floating point or fixed precision numbers. This would probably have some performance implications though. Edit: On second thought this is...

> > This seems like a result of not being aware of physical pixels on framework level. > > @knopp I think it's the opposite - we are supposed to...

@hellohuanlin if you have RectA (0, 0, 1.1, 1.1) and RectB (1.1, 1.1, 2, 2), they don't overlap, geometric intersection will tell you that they don't overlap. But we don't...

> They do overlap from that perspective, unless the platform view is opaque and ontop . However the overlap is small and I think of the cost is severe enough...

For the record, [here](https://github.com/knopp/flutter_ads_list_perf/commits/pixel_snap/) is the flutter_ads_list_perf example snapped to physical pixels. As expected this solves the problem, the only overlay seems to be one for the debug banner. Unfortunately...