Change Window scale factor to f32

[thmsgntz]

Hi!
This is my first contribution! I am not familiar yet with everything in Bevy so I am opened to criticism to learn :)

Objective

Fixes #8900

Solution

• Changed scale_factor of Window and UI from f64 to f32

---

Changelog

Structs changed:

• bevy_ui: layout_context
• bevy_ui: UI_Scale
• bevy_window: WindowResolution
• carmera.rs: RenderTargetInfo

Tests changed:

• examples/ui/ui_scaling.rs

Migration Guide

If manipulating scale_factor, some conversion from f64 to f32 may be necessary.

[github-actions]

Welcome, new contributor!

Please make sure you've read our contributing guide and we look forward to reviewing your pull request shortly ✨

[thmsgntz]

Hmm cargo -p run ci passes well on my computer. Checking these errors.

EDIT: oh ok I need to rebase on main, did not see the changes on main. Working on it.

[alice-i-cecile]

Great! We need a second approval before we can merge this :)

In this case I'm going to pull in both @JMS55 (rendering expert) and @ickshonpe (UI expert who requested the change).

P.S. I couldn't request ickshonpe as a reviewer because you're not in the Bevy org; bug @cart for membership and triage powers?

[ickshonpe]

I'll take a look when I get home this evening.

[ickshonpe]

These are the changes I had in mind when I wrote up this issue, and the implementation looks good. I'll run through some examples just to make sure everything is okay.

I should have written up the original issue better though. For Bevy UI there should be no problems, even with something silly like a resolution ten times larger than 8k single-precision floats should be enough. But I don't know if (for example) there might be complications caused by the changes to Camera for people running simulations of very large worlds. There should also be a reason why winit uses double-precision too (HIDPI?), I'd like to know that as well.

I think even if there are complications, they wouldn't block most of the changes as we can just convert the values from Window at access and otherwise use f32s internally.

[nicoburns]

The other case in which there could be issues is very long scrollable views. But fixing this would likely require f64 everywhere (or a fixed point value where 1 = 1/60th like web browsers use), not just for the scale factor.

[alice-i-cecile]

Are you planning to remake this from an alternate branch?

[thmsgntz]

back online, my bad.

[hymm]

should ease_in_expo be changed to take a f32 also?

[alice-i-cecile]

@thmsgntz can you please resolve the merge conflicts so we can merge this? @ickshonpe, can I get your review?

[thmsgntz]

@thmsgntz can you please resolve the merge conflicts so we can merge this? @ickshonpe, can I get your review?

Sure, I will have some free time this weekend to work on it

[thmsgntz]

I think I'm done but I need help to fix these problems with cargo doc :(

cargo run -p ci -- doc returns :

error: redundant explicit link target
   --> crates/bevy_reflect/bevy_reflect_derive/src/derive_data.rs:425:112
    |
425 | ...rom the [`members_to_serialization_denylist`](crate::utility::members_to_serialization_denylist) function.
    |             -----------------------------------  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ explicit target is redundant
    |             |
    |             because label contains path that resolves to same destination
    |
    = note: when a link's destination is not specified,
            the label is used to resolve intra-doc links
    = note: `-D rustdoc::redundant-explicit-links` implied by `-D warnings`
help: remove explicit link target
    |
425 |     /// The returned bitset is a collection of indices obtained from the [`members_to_serialization_denylist`] function.
    |                                                                          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

error: could not document `bevy_reflect_derive`

And I do not know how to fix errors from cargo run -p ci -- compile like this one :

test tests/ui/system_state_iter_mut_overlap_safety.rs ... mismatch

EXPECTED:
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
error[E0502]: cannot borrow `query` as immutable because it is also borrowed as mutable
  --> tests/ui/system_state_iter_mut_overlap_safety.rs:18:13
   |
15 |         let mut_vec = query.iter_mut().collect::<Vec<bevy_ecs::prelude::Mut<A>>>();
   |                       ---------------- mutable borrow occurs here
...
18 |             query.iter().collect::<Vec<&A>>(),
   |             ^^^^^^^^^^^^ immutable borrow occurs here
...
23 |             mut_vec.iter().map(|m| **m).collect::<Vec<A>>(),
   |             -------------- mutable borrow later used here
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈

ACTUAL OUTPUT:
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
error[E0502]: cannot borrow `query` as immutable because it is also borrowed as mutable
  --> tests/ui/system_state_iter_mut_overlap_safety.rs:18:13
   |
15 |         let mut_vec = query.iter_mut().collect::<Vec<bevy_ecs::prelude::Mut<A>>>();
   |                       ----- mutable borrow occurs here
...
18 |             query.iter().collect::<Vec<&A>>(),
   |             ^^^^^ immutable borrow occurs here
...
23 |             mut_vec.iter().map(|m| **m).collect::<Vec<A>>(),
   |             ------- mutable borrow later used here
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
note: If the actual output is the correct output you can bless it by rerunning
      your test with the environment variable TRYBUILD=overwrite

[alice-i-cecile]

Adopted in #10897 <3 Thanks for getting this started!