Make Viewport::default() return a 1x1 viewport

[SludgePhD]

Objective

• The current default viewport crashes bevy due to a wgpu validation error, this PR fixes that
• Fixes Viewport::default() produces a viewport that always crashes #14355

Solution

• Viewport::default() now returns a 1x1 viewport

Testing

• I modified the 3d_viewport_to_world example to use Viewport::default(), and it works as expected (only the top-left pixel is rendered)

[github-actions]

It looks like your PR is a breaking change, but you didn't provide a migration guide.

Could you add some context on what users should update when this change get released in a new version of Bevy?
It will be used to help writing the migration guide for the version. Putting it after a ## Migration Guide will help it get automatically picked up by our tooling.

[BD103]

This is technically a breaking change, but it should probably be added to 0.14.1 because it had incorrect behavior before.

[SludgePhD]

This is technically a breaking change

How so? A change like this wouldn't normally be considered breaking.

[BD103]

This is technically a breaking change

How so? A change like this wouldn't normally be considered breaking.

A breaking change doesn't have to be something that would make code fail to compile, it can also be a behavioral change. In this case, someone may depend on the fact that Viewport::default().physical_size is (0, 0). (In practice, this probably will never happen, but it's still good to make a note of it just in case. The worst thing that can happen is that we don't document it, and then someone cannot figure out why their code no longer works.)

[SludgePhD]

A breaking change doesn't have to be something that would make code fail to compile, it can also be a behavioral change. In this case, someone may depend on the fact that Viewport::default().physical_size is (0, 0). (In practice, this probably will never happen, but it's still good to make a note of it just in case. The worst thing that can happen is that we don't document it, and then someone cannot figure out why their code no longer works.)

Yeah, but that's pushing the definition of "breaking" too far IMO. Not my project though, so I was mostly asking to know if this requires some action on my part.

[BD103]

No, you're right. I thought about it some more, and since the behavior was never right in the first place, it should probably not be considered breaking. Sorry for the confusion!