search

rust-windowing / softbuffer

Easily write an image to a window
Apache License 2.0
333 stars 48 forks source link

Allow querying configured size #237

Open madsmtm opened 2 months ago

madsmtm commented 2 months ago

Surface::height / Surface::width would be nice to have, instead of having to query them from the window.

MarijnS95 commented 2 months ago

We should intrinsically take #177 into account when tackling this issue. On most platforms it appears window size (appearance on screen) != surface size (physical dimensions of a pixel buffer) is natively supported (by relying on scaling hardware via the compositor) and should be exposed to the user one way or the other.

MarijnS95 commented 2 months ago

On Android we "have to" call ANativeWindow_setBuffersGeometry() to change the buffer format, "and set a size". But it explicitly documents:

For all of these parameters, if 0 is supplied then the window's base value will come back in force.

And if I set the width and height to 0, the NativeWindowBufferLockGuard / ANativeWindow_Buffer struct returned by self.native_window.lock() contains the actual size of the buffer at that point in time, and follows resizes caused by the system. (If we set a size ourselves, #177 with hardware scaling comes into effect).

So realistically (for #237) we should have the actual size available on the Buffer and allow Surface to either resize to a user-specified value, or to a "special value" where it automatically follows the "window size" all the time (which the user reads back on Buffer whenever it's "locked for writing")?

MarijnS95 commented 2 months ago

So it looks like we have 3 situations:

  1. User doesn't set (or discards/resets) a Surface size. They read back the size of Buffer every time they draw, and expect this to follow the Window size;
  2. User specifically requests a pixel size on Surface (which may or may not affect the size of the window on-screen) and can expect the returned Buffer to match;
  3. If the Window size doesn't change (or we have an API to control that separately, or they control it via e.g. winit), they get implicit (hardware) scaling?
madsmtm commented 2 months ago

Yeah, that sounds right to me.

Question now is, do we want to support all of them? Would we be fine with not having hardware scaling, and just always have the buffer be the size of the surface? So e.g. remove resize, and add Buffer::width and Buffer::height (in case the buffer is used concurrently with the surface being changed)?

MarijnS95 commented 2 months ago

@madsmtm removing resize() is a step in the right direction to remove confusion and backend inconsistencies (does the user call this on startup? When their windowing system raises a resized event? When they want to change the size of the surface and possibly even the wrapped window?). And we could always reintroduce hardware scaling via a different/new function that more clearly annotates this?

And also, if possible on all platforms, redirect the user to their windowing system docs to resize the window if necessary.