Remove NonZero from Rect.width and Rect.height#345
Conversation
These now use `u32` instead of `NonZeroU32`. This is always valid, a zero-sized damage rectangle can just be ignored.
| /// Zero-sized damage regions (rectangles with `width` or `height` equal to `0`) may be | ||
| /// completely ignored, or may end up increasing the "union" damage region to contain the | ||
| /// zero-sized rectangle too. This is platform-specific, and should not be relied upon. |
There was a problem hiding this comment.
I lied a bit above, there is actually a small wrinkle with zero-sized rects, and that's when you consider how they work in unions.
Consider something like:
buffer
.present_with_damage(&[
Rect {
x: 10,
y: 20,
width: 30,
height: 0,
},
Rect {
x: 100,
y: 200,
width: 0,
height: 40,
},
])
.unwrap();If you naively union those, it'll present Rect { x: 10, y: 20, width: 100, height: 220 }, which might be undesirable?
I'll need to test all backends with it to see how they actually handle the rects in practice (whether they "union" them or ignore them). Also need to check what AppKit does.
I'm pretty sure they all ignore them, if so, we could probably document here (and implement in util::union_damage) that zero-sized rectangles are ignored too.
notgull
left a comment
There was a problem hiding this comment.
I don't think we should move away from nonzero for the same reasons I voiced here: #238 (comment)
These now use
u32instead ofNonZeroU32. A zero-sized damage rectangle can very easily be ignored, meaning that there is no real downside of allowing the user to specify them.Part of #238.
Split out from #295, this should make sense to do regardless of what we end up doing with surface widths/heights.
See relatedly #314 which also relaxed the checks on damage regions.
Tested on: