Include rounded corner radius in android safe area implementation #6143
Conversation
Android apparently has a separate API for "window cutouts", i.e. for cameras and the like, and a separate API for "rounded corners", i.e. devices where the rounded corners of the display will cause some areas of the theoretically-rectangular display to be obscured. Because there is no engineering like overengineering, right? Bonus points for them being usable at different API levels, too. Disclaimer that this does absolutely nothing on my one test device that has a rounded display and a high enough API level, but honestly it may be a device issue since it's not even returning `true` for `WindowInsets.IsRound`. Maybe it'll help someone, no idea.
|
Reading the code, I'm guessing that the resulting safe area is less than optimal.
It would make way more sense if the code only cut away from the longest screen side (resulting in what I colored orange), or if optimizing for most play area only 1-sqrt(2)/2 of the radius should be cut away (resulting in what I colored green). Hopefully someone can test what the resulting screen actually looks like. Also there's a TODO still left in. |
| var radiusInsetArea = screenArea.Shrink(cornerInsetLeft, cornerInsetRight, cornerInsetTop, cornerInsetBottom); | ||
| usableScreenArea = usableScreenArea.Intersect(radiusInsetArea); |
There was a problem hiding this comment.
I think the math here is too conservative. See the illustration (green would be considered the safe area):
It should either apply top & bottom or left & right padding, not both at the same time.
|
I'm more for the orange solution as it matched what other games do & doesn't complicate things with 4-side padding. The green solution is too simple and not a true optimal area, as it doesn't consider the width and height of the screen (if the screen is really tall, it would be optimal to push the corner point towards the orange solution). |
|
can anyone with an iOS device say what iOS does with rounded corners? @frenzibyte @peppy? |
|
I think this is accurate, except the bottom safe area edge is overriden locally.
|
|
iPhone 12:
|
|
that looks weird because it cuts out mostly at the long edge but also appears to cut out a bit on the short edge? i dunno. think i'm just gonna make it cut at the long edge and hope everyone here can be satisfied with that. |
bdach
force-pushed
the
rounded-corners-android
branch
from
60ea37d
to
471d5e9
Compare
| int cornerInsetTop = Math.Max(topLeftCorner?.Radius ?? 0, topRightCorner?.Radius ?? 0); | ||
| int cornerInsetBottom = Math.Max(bottomLeftCorner?.Radius ?? 0, bottomRightCorner?.Radius ?? 0); | ||
|
|
||
| var radiusInsetArea = screenArea.Width >= screenArea.Height |
There was a problem hiding this comment.
i hope i can be forgiven for probably imperfectly handling square screens
There was a problem hiding this comment.
semi serious, safe area is a setting, right? This isn't going to break someone using osu-framework on a smart watch?
There was a problem hiding this comment.
it's not a setting, and i have absolutely no idea, can we skip that question?
that's just the bezel |
Android apparently has a separate API for "window cutouts", i.e. for cameras and the like, and a separate API for "rounded corners", i.e. devices where the rounded corners of the display will cause some areas of the theoretically-rectangular display to be obscured. Because there is no engineering like overengineering, right? Bonus points for them being usable at different API levels, too.
Disclaimer that this does absolutely nothing on my one test device that has a rounded display and a high enough API level, but honestly it may be a device issue since it's not even returning
trueforWindowInsets.IsRound. Maybe it'll help someone, no idea.