hellohuanlin

> 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 do geometric intersection...

> Well, yes, but if content was snapped to physical pixes then the roundOut would not do anything. So you would not get the overlap. Not sure how "snapping" works....

> @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...

Let's bring the discussion to real time chat on discord if it's easier. @knopp I couldn't find your username there, so here's the link: https://discord.com/channels/608014603317936148/608021010377080866/1209974674696437781

> The proposed solution basically means if there is an intentional 1px hairline overlay somewhere it will not be rendered. Is that common? Is that going to be a problem?...

> Now both situations could be called "hairlines", but the way that they intersect the platform view can make them seem intentional or accidental. The first case is what I...

> I can't imagine that anyone would find value in drawing over just a single pixel (wide/tall) sliver on the edge of a platform view. Strongly agreed! > One issue...

> I think you need to rebase to ToT due to the infra misconfiguration causing the ci.yaml step to fail. Oh this is just a draft PR that I open...

> I think this should also fix https://github.com/flutter/flutter/issues/138656, where we end up creating a fullscreen blur due to the 1px overlay layer. Let me take a look.

These 2 are different use cases: (1) the existing doc is to present the flutter VC as a screen. This is the most common use case (e.g. migrate some screens...