Prefer UVec2 when working with texture dimensions

[CptPotato]

Objective

The physical width and height (pixels) of an image is always integers, but for GpuImage bevy currently stores them as Vec2 (f32). Switching to UVec2 makes this more consistent with the underlying texture data.

I'm not sure if this is worth the change in the surface level API. If not, feel free to close this PR.

Solution

• Replace uses of Vec2 with UVec2 when referring to texture dimensions.
• Use integer types for the texture atlas dimensions and sections.

Sprite::rect remains unchanged, so manually specifying a sub-pixel region of an image is still possible.

---

Changelog

• GpuImage now stores its size as UVec2 instead of Vec2.
• Texture atlases store their size and sections as UVec2 and URect respectively.
• UiImageSize stores its size as UVec2.

Migration Guide

• Change floating point types (Vec2, Rect) to their respective unsigned integer versions (UVec2, URect) when using GpuImage, TextureAtlasLayout, TextureAtlasBuilder, DynamicAtlasTextureBuilder or FontAtlas.

[CptPotato]

Is it worth keeping Image::size_f32()?

bevy/crates/bevy_render/src/texture/image.rs

Lines 556 to 560 in 36804dc

	/// Returns the size of a 2D image as f32.
	#[inline]
	pub fn size_f32(&self) -> Vec2 {
	Vec2::new(self.width() as f32, self.height() as f32)
	}

width and height are integers anyways, so this is just a minor convenience over using .size().as_vec2().

[alice-i-cecile]

This makes far more sense to me: if we're just converting them to integers at the end anyways we should store and accept these values as ints.

[Kanabenki]

Might make sense to turn this into an URect?

[CptPotato]

Good point, I'll give it a try and see if this causes conflicts anywhere.

As a side question: Is it a valid use case to specify fractional portions for the textures in a texture atlas? With URect I don't think it would be possible anymore. TextureAtlasLayout::from_grid is a similar story, now that I look at it.

[Kanabenki]

I don't think sub-pixel indexing is a use case needed in the texture atlas code from a quick skimming of it, and if a user need for some reason to do some fractional indexing, they can still convert from UVec2 to Vec2. To be consistent some similar changes would also be needed in TextureAtlasBuilder, but that can be done in another PR 🙂

[CptPotato]

I adjusted the types in TextureAtlasLayout and TextureAtlasBuilder to use "u32" types (URect, etc.) as you suggested. Though, because of these changes I also had to update a bit more code than I would have like.

Interactions with guillotiere are also a bit odd because these types use i32 instead of u32. So theres a few as i32 here and there.

[alice-i-cecile]

Going to wait on the URect changes; ping me (or add the Ready-For-Final-Review label) if that's done and it's been a while.

[CptPotato]

I think I'm mostly done with my changes. Will rebase soon and probably finish it up this weekend (still have to test that I didn't break things).

Also, I left Sprite::rect unchanged as Vec2, because I think it's ok to allow users to specify sub-pixel areas if they want to.

[alice-i-cecile]

CI failures are real: looks like you need to fix up some examples.

[CptPotato]

Yup, I also think #11783 will cause additional conflicts (even though they're trivial to solve). I'd wait for that PR, since I think it's a less controversial change and could be merged relatively quickly.

[CptPotato]

Sorry for the longer than expected delay. I rebased onto main and verified that the 2D sprite examples have identical output compared to main. CI should also be good now.