Repository navigation
Viewport2 should clip visual overflow - #7641
Conversation
There was a problem hiding this comment.
should be tested in debugAssertIsValid and printed in toString
There was a problem hiding this comment.
you can remove this todo now :-)
There was a problem hiding this comment.
it also overflows if scrollOffset > 0.0
There was a problem hiding this comment.
these should each have a comment saying that we're being extra-conservative here to trade the cost of calculating whether we have overflow for the cost of always doing clipping.
There was a problem hiding this comment.
I don't understand the second term of this or.
Surely we have overflow any time constraints.scrollOffset is greater than 0.0? (Unless we happen to be really lucky and be exactly on a child boundary at our leading edge, but it seems like turning clipping on and off if we happen to hit that boundary is going to be pointless if not extra expensive.)
There was a problem hiding this comment.
actual [Canvas.clipRect] call's argument, singular
There was a problem hiding this comment.
we should document somewhere (in this file's docs) that we're implying a save/restore pair when you call pushClipRect.
There was a problem hiding this comment.
The real PaintingContext does this too.
There was a problem hiding this comment.
i don't understand how this passes today
There was a problem hiding this comment.
Oh never mind, this is for SliverBlock. I thought it was testing SliverToBoxAdapter.
There was a problem hiding this comment.
add a test identical to this one but with height < 600 and i think it'll fail.
|
I'm worried that this bit is just as complicated to get right as the other dimensions in SliverGeometry, but we can give it a try. LGTM. |
When you put a box in a Viewport2, it might paint outside its allocated bounds. This patch teaches Viewport2 to clip when that happens.
3 participants
When you put a box in a Viewport2, it might paint outside its allocated bounds.
This patch teaches Viewport2 to clip when that happens.