rust-windowing
Handle zero-sized buffers internally
The NonZeroU32 in our public API is ugly IMO. Is there a reason why we avoid resizing and rendering when the sizes are 0? Does it crash on some backends? Could we instead make it be a no-op?
See also discussion in https://github.com/rust-windowing/softbuffer/pull/236#discussion_r1740169764.
Using NonZeroU32 seems to match glutin: https://docs.rs/glutin/latest/glutin/surface/trait.GlSurface.html#tymethod.resize.
Meanwhile, https://docs.rs/wgpu/25.0.2/wgpu/type.SurfaceConfiguration.html uses u32, but documents width and height with "Must be the same size as the surface, and nonzero.".
(I seem to recall some discussion about changing winit to return the size as NonZeroU32, but I don't see anything, and I guess it's still u32 in git.)
So it seem to make some sense from a consistency standpoint.
On Wayland, https://wayland.app/protocols/wayland#wl_shm_pool:request:create_buffer doesn't really seem to properly document the error cases, but checking smithay and wlroots, they generate invalid_stride errors if 0 or a negative value is passed for width or height. It is possible to attach null instead of a wl_buffer to a surface, but this has the effect of hiding/unmapping a window.
So on Wayland anyway, there isn't really a concept of having a window containing a 0x0 buffer. To implement that without crashing the client with a protocol error, we'd have to special case it as either a null buffer (unmapping the window) or perhaps a 1x1 transparent buffer.
IIRC CGImageCreate will also fail if you provide 0 width/height. What I meant here was to special-case 0-sized buffers, and just no-op in Buffer::present (but still provide the empty pixels slice to users and everything).
The reason I think this makes a lot of sense is if you want to use softbuffer for subsurfaces, as those are a lot more likely to be zero-sized in some dimension.
I get that this might has weird interactions with surfaces that are tied to a window, not sure what we'd want to do there.
I seem to recall some discussion about changing winit to return the size as
NonZeroU32
Maybe https://github.com/rust-windowing/winit/issues/3433#issuecomment-1954061753?
In what case would a subsurface be "a lot more likely to be zero-sized in some dimension"? If it is for presenting something, or catching user-input in specific places, it has to have a surface area hence nonzero dimensions, right?
Matching the wayland null example above, should we find a way to return a None Buffer instead if/when this is the case?
Or when thinking about hardware scaling in #177 altogether, let the user request/create nonzero-sized buffers on their own regard (on platforms that support this) and present these into arbitrary sized surfaces?
In what case would a subsurface be "a lot more likely to be zero-sized in some dimension"? If it is for presenting something, or catching user-input in specific places, it has to have a surface area hence nonzero dimensions, right?
Depends on how fine-grained you make your subsurfaces (which is kinda theoretical anyhow since Winit doesn't support it at all yet), but I could easily imagine e.g. a subsurface for a sidebar in an editor, which you want to be able to minimize and expand with an animation. In that case, it'd make sense to still keep the 0x1000px "surface" around when the sidebar is collapsed.
Okay, makes sense.
Replying to resizing in the OP; did we discuss in a different thread/issue why a resize op needed to be "forwarded" from winit to softbuffer in the first place? Especially wrt hardware scaling?
(Well, realistically it should control the logical size of the surface in the layer stack / composition tree?)
Replying to
resizingin the OP; did we discuss in a different thread/issue why a resize op needed to be "forwarded" from winit to softbuffer in the first place? Especially wrt hardware scaling?(Well, realistically it should control the logical size of the surface in the layer stack / composition tree?)
I don't think we've discussed it. Maybe a bit in https://github.com/rust-windowing/softbuffer/issues/177? Or maybe open a new issue?
It looks like that was discussed in https://github.com/rust-windowing/softbuffer/pull/236 first and subsequently "tracked" in https://github.com/rust-windowing/softbuffer/issues/237. If that's not adequate we should split out a new issue.