Skip to content
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

Merged
merged 6 commits into from
Sep 4, 2024
Merged

Conversation

madsmtm
Copy link
Member

@madsmtm madsmtm commented Aug 24, 2024

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 and glutin 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).

  • Tested on all platforms changed
  • Added an entry to the changelog module if knowledge of this change could be valuable to users
  • Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior

@madsmtm madsmtm added S - api Design and usability S - docs Awareness, docs, examples, etc. I - BREAKING CHANGE labels Aug 24, 2024
Copy link
Member

@MarijnS95 MarijnS95 left a 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.

Comment on lines 203 to +204
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)));
Copy link
Member

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)?

Comment on lines 201 to 202
let old_scale_factor = scale_factor(&self.android_app);
let scale_factor = scale_factor(&self.android_app);
Copy link
Member

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?

Comment on lines +811 to 812
fn surface_size(&self) -> PhysicalSize<u32> {
self.outer_size()
Copy link
Member

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()?

Copy link
Member Author

@madsmtm madsmtm Aug 24, 2024

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

Copy link
Member

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

@madsmtm
Copy link
Member Author

madsmtm commented Aug 24, 2024

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

@kchibisov
Copy link
Member

inner_size is the rendering surface size.
outer_size is the size of the window with other stuff (like decorations).
resize_increments is resizing step for the window, not surface.

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.

@madsmtm
Copy link
Member Author

madsmtm commented Aug 25, 2024

inner_size is the rendering surface size.

Yeah, and that's why I'm changing it to be named that way.

resize_increments is resizing step for the window, not surface.

Not on macOS at least, we set contentResizeIncrements there, see discussion here.

Also IMO what's desired, you don't care about window decorations when setting resize increments.

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.

I'm aware, and I intend to address this discrepancy in a different PR than this one. EDIT: See #3890

@xorgy
Copy link

xorgy commented Aug 25, 2024

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 .

@madsmtm
Copy link
Member Author

madsmtm commented Aug 26, 2024

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!

@MarijnS95
Copy link
Member

@madsmtm unfortunately on Android that info only seems to be available inside DisplayCutout which is some more JNI that I'm not ready to have in winit just yet - but we could/should push it into android-activity instead.

@madsmtm
Copy link
Member Author

madsmtm commented Aug 26, 2024

@madsmtm unfortunately on Android that info only seems to be available inside DisplayCutout which is some more JNI that I'm not ready to have in winit just yet - but we could/should push it into android-activity instead.

Unfortunate. But then I'd be happy with just ensuring that the implementation for surface_position is correct, and then return (0, 0), (width, height) from safe_area on Android for now.

@xorgy
Copy link

xorgy commented Aug 27, 2024

@madsmtm unfortunately on Android that info only seems to be available inside DisplayCutout which is some more JNI that I'm not ready to have in winit just yet - but we could/should push it into android-activity instead.

Shouldn't be a huge mess, just a bit of ugly JNI. Mads' model for a safe area might also involve specifically dealing with RoundedCorner (which affects the safe rectangle in fullscreen mode, but generally not otherwise).

Copy link
Member

@daxpedda daxpedda left a 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!

@madsmtm madsmtm merged commit 8db3e0e into master Sep 4, 2024
58 checks passed
@madsmtm madsmtm deleted the madsmtm/inner-to-surface branch September 4, 2024 13:04
///
/// See [`Window::set_surface_resize_increments`] for details.
#[inline]
pub fn with_surface_resize_increments<S: Into<Size>>(
Copy link
Member

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>>;
Copy link
Member

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>);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

window.

@madsmtm
Copy link
Member Author

madsmtm commented Sep 4, 2024

I've opened #3900 for the resize increments discussion

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I - BREAKING CHANGE S - api Design and usability S - docs Awareness, docs, examples, etc.
Development

Successfully merging this pull request may close these issues.

5 participants