-
Notifications
You must be signed in to change notification settings - Fork 909
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rename "inner size" to "surface size" #3889
Conversation
To make it clear which size the increments apply to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes a lot of sense for Android, but it looks like there's some more (slightly irrelevant to this PR) cruft in its backend to clean up.
if (scale_factor - old_scale_factor).abs() < f64::EPSILON { | ||
let new_inner_size = Arc::new(Mutex::new(screen_size(&self.android_app))); | ||
let new_surface_size = Arc::new(Mutex::new(screen_size(&self.android_app))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the surface size in pixels on Android affected by a scale factor, or has it been observed to change when the scale factor changed)?
let old_scale_factor = scale_factor(&self.android_app); | ||
let scale_factor = scale_factor(&self.android_app); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Barring race conditions, this function appears reentrant and would always return the same value?
fn surface_size(&self) -> PhysicalSize<u32> { | ||
self.outer_size() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we invert this - make fn inner_size()
return screen_size()
and make fn outer_size()
return self.inner_size()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect "inner_size" here may refer to the safe area, and "outer size" to without safe area? Not sure though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure either, but that could be how we intend to do it later in which case we better leave the surface_size()
== outer_size()
(with possible cut-outs, transparent system UI overlaps etc).
I was thinking of this in terms like Windows' windows for a while, where the drawable area/surface excludes the window decorations AFAIK. Android has a floating-window mode as well but that "outer size" is probably not easily exposed, not via the NDK at least...
I will clean up the iOS backend, and attempt the same for the Android backend later (and will use your comments as a guide), but I want to keep it out if this PR which is strictly a rename |
inner_size is the rendering surface size. safe area is completely different concept and doesn't affect any rendering or buffers created, in fact, using safe area as a size for rendering surface is completely wrong. Safe area should only be used to offset your content within the surfare_size buffer. |
Yeah, and that's why I'm changing it to be named that way.
Not on macOS at least, we set Also IMO what's desired, you don't care about window decorations when setting resize increments.
I'm aware, and I intend to address this discrepancy in a different PR than this one. EDIT: See #3890 |
This is a major improvement for us as well. I can wire through a basic Android implementation of inner vs surface sizing, if you don't want to @madsmtm . |
Yeah, I think I could use some help with the Android backend, if you or Marijin could open a PR targetting the branch in #3890, that'd be nice! |
@madsmtm unfortunately on Android that info only seems to be available inside |
Unfortunate. But then I'd be happy with just ensuring that the implementation for |
Shouldn't be a huge mess, just a bit of ugly JNI. Mads' model for a safe area might also involve specifically dealing with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, very nice improvement!
/// | ||
/// See [`Window::set_surface_resize_increments`] for details. | ||
#[inline] | ||
pub fn with_surface_resize_increments<S: Into<Size>>( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Resize increments are for window.
/// | ||
/// ## Platform-specific | ||
/// | ||
/// - **iOS / Android / Web / Wayland / Orbital:** Always returns [`None`]. | ||
fn resize_increments(&self) -> Option<PhysicalSize<u32>>; | ||
fn surface_resize_increments(&self) -> Option<PhysicalSize<u32>>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's window.
/// | ||
/// ## Platform-specific | ||
/// | ||
/// - **macOS:** Increments are converted to logical size and then macOS rounds them to whole | ||
/// numbers. | ||
/// - **Wayland:** Not implemented. | ||
/// - **iOS / Android / Web / Orbital:** Unsupported. | ||
fn set_resize_increments(&self, increments: Option<Size>); | ||
fn set_surface_resize_increments(&self, increments: Option<Size>); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
window.
I've opened #3900 for the resize increments discussion |
As discussed in #2308, using "inner" in the name is confusing, and could mean many different things. Let's rename it to "surface", and define that to mean the size of the drawable surface, i.e. the dimensions that
wgpu
andglutin
should be configured with.See the changelog entry for the full list of changed APIs.
Some backends (at least iOS/UIKit) are still not be returning the actual surface size, but I wanted to address that separately (along with introducing
Window::safe_area
).changelog
module if knowledge of this change could be valuable to users