-
-
Notifications
You must be signed in to change notification settings - Fork 114
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
Pixels no longer handles scaling factors correctly. #330
Comments
A thought did occur that last time I used Pixels was on a desktop with scale factor set to 100%. So it probably always been the case that Pixels has misbehaved with regard to scale factor. |
It doesn't necessarily misbehave with the scale factor, though. We have a scale factor of 2.0 on macOS, and all of the examples work fine there. And this may in fact be the problem (see below). But I do have a couple of observations.
My leading theory at the moment is that a scale factor with a non-integer value (like 1.25) is not going to work as intended. First, let's assume your target texture resolution is 320x200, which is a common VGA display resolution. And the scale factor is 1.25.
Also note that #262 will hide this problem, and only real pixel purists (me...) would notice it exists. Footnotes
|
Thanks for the reply. I was using physical pixels only throughout the code (so I completely agree with your assessment here). My foray into logical pixels was to stop Pixels from crashing. Here's the bug (I believe) I face in one sentence: That is, I pass exactly the same physical size into either I resize the buffer when either I get a I will attempt to get you some minimal code. I think the example on the |
Until I find a way to reproduce the panic with a 1.0 or 2.0 scale factor, a backtrace will be somewhat helpful for further diagnostics. |
I noticed I can get the panic with scale factor 1.0 iff the buffer height is set larger than the surface height. This panic is probably appropriate, and we might want a similar check on the width. Here's is my minimal repro: diff --git a/examples/minimal-winit/src/main.rs b/examples/minimal-winit/src/main.rs
index ae0b6c1..d0828f1 100644
--- a/examples/minimal-winit/src/main.rs
+++ b/examples/minimal-winit/src/main.rs
@@ -42,6 +42,8 @@ fn main() -> Result<(), Error> {
};
let mut world = World::new();
+ pixels.resize_buffer(WIDTH, HEIGHT + 1);
+
event_loop.run(move |event, _, control_flow| {
// Draw the current frame
if let Event::RedrawRequested(_) = event { And the backtrace:
|
That's the same assert I get if they are equal and scale factor is 1.25. |
I am having trouble understanding how it would panic with the values you've described. If the surface and the backing texture are the same size, the divisions in there will just result in Lines 233 to 236 in bf296a4
Maybe you could add let scale = dbg!(dbg!(screen_width) / dbg!(texture_width))
.clamp(1.0, dbg!(dbg!(screen_height) / dbg!(texture_height)))
.floor(); |
@Cthutu Were you able to add the |
Not yet - sorry. Been incredibly busy IRL, but as more time passed, I just
forgot about it. I will try to rustle something together over
the weekend. It happened when I was updating the version of pixels and
building my example for the `pixels-u32` crate.
…On Thu, 26 Jan 2023 at 17:17, Jay Oster ***@***.***> wrote:
@Cthutu <https://github.com/Cthutu> Were you able to add the dbg!()s to
help with troubleshooting on this issue? Without more info, I don't know
what else I can do, here.
—
Reply to this email directly, view it on GitHub
<#330 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACVDRTC2L7UFH4Y6Q5O2KTWUKWR3ANCNFSM6AAAAAATUUKDMM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I'm in the process of updating dependencies and noticed that the new version of let width_ratio = (screen_width / texture_width).max(1.0);
let height_ratio = (screen_height / texture_height).max(1.0);
// Get smallest scale size
let scale = width_ratio.clamp(1.0, height_ratio).floor(); You can try this out if you like. It might help in your case? I think it might actually cause some unwanted stretching in some cases, especially if you have provided any incorrect dimensions anywhere. But this is currently what I am planning to implement for the next release. |
* Update wgpu to 0.15 * Fix the panic described in #330 * Specify `min_binding_size` since we know what it is.
I used to be able to set the surface and buffer physical sizes to the same and it would work. I would have a pixel buffer that filled my current window (who's surface matched the window's inner size). Now pixels asserts when resizing the surface and buffer to the same sizes when scale factor is not 1. This assertion happens inside the
clamp
function.Even the examples do not correctly function with a scale factor other than 1. For example in
minimal-winit
you get a thick black border around the rendered area.Right now, I can't see any method where I can get the buffer and the window the same size when scale factor is not equal to 1. And therefore, I am unable to update to a newer pixels version.
What I would expect:
This is the minimal winit example with scale factor of 125%
This is the minimal winit example with scale factor of 100%
Consequently, switching scale factor while the minimal winit example is running causes a crash.
The text was updated successfully, but these errors were encountered: