[iOS] Sync the boot splash and the launch screen image scale modes

[jkirsteins]

What does this PR address?

Using iOS launch screens for the boot splash is not aligned with how Godot renders the boot splash.

On iOS the splash screen with launch images happens in two stages:

• show the launch screen (the export template allows modifying the scale mode - aspect fit, aspect fill etc.)
• afterwards Godot takes over, and renders the splash screen. Godot does not take into account the iOS splash scale mode so when it takes over, there is a visual tear as the splash changes dimensions and position.

This is partially addressing #81389 (though this PR does not address any compatibility issues with the legacy renderer)

Change outline

• I added two methods in Vector2 for fitting Vector2 inside another Vector2, either with aspect-fit-center or aspect-fit-cover modes (analogous to what the TextureRect exposes)
• I added Vector2 tests to verify the calculated areas
• I refactored RendererCompositorRD to allow the OS singleton to calculate the splash area. The iOS singleton will fetch the aspect mode from Info.plist and calculate a matching area. Others will keep existing behavior.

Testing

Here's some visual examples of the effect.

Landscape - export template specifies "scale to fill"

Before the changes:

bad__landscape__keepAspectCovered__scaleToFill.mov

After the changes:

good__landscape__keepAspectCovered__scaleToFill.mov

Portrait - export template specifies "scale"

Before the changes:

bad__portrait__scale__scale.mov

After the changes:

good_portrait__scale__scale.mp4

[bruvzg]

Seems to be working as expected.

[AThousandShips]

Please try to avoid pushing so many times in a row (10 times in 35 minutes), it really puts pressure on the automatic checks

[jkirsteins]

Please try to avoid pushing so many times in a row (10 times in 35 minutes), it really puts pressure on the automatic checks

Apologies, I didn't realize. Will avoid that.

[akien-mga]

The additions to Vector2 and OS seem highly specific and not really warranted to be core additions.
Edit: For OS I see it's needed for rendering so I guess it's fine.

Please add such code as helper methods where it's needed and not in core - see https://docs.godotengine.org/en/stable/contributing/development/best_practices_for_engine_contributors.html#prefer-local-solutions

[akien-mga]

I don't see (a priori) a reason to add a new API to Vector2 to calculate some boot splash metrics.

In second review, I see the OS one is used in RendererRD so I guess that's needed, though that still feels a bit weird architecture wise.

[jkirsteins]

Thanks for the prompt feedback everyone.

I don't see (a priori) a reason to add a new API to Vector2 to calculate some boot splash metrics.

I'll move the methods. But just to share my thought process - I chose adding them to the core, because the functionality itself (fitting a size inside another size given a stretch mode) is not specific to iOS. In fact, this code already exists (it is essentially what TextureRect does with its stretch modes). But since that code is located in TextureRect, I couldn't cleanly reuse it.

So my rationale was that by putting this in core, it could help unify this type of aspect fitting logic in the future.

However, I see how my approach does not fully align with existing conventions, so I'm happy to move it.

In second review, I see the OS one is used in RendererRD so I guess that's needed, though that still feels a bit weird architecture wise.

An obvious other solution could be to have an OS-specific branch in the RendererRD, but I think it is also not ideal (there is no precedent to branch like that in this class). However, as it's a small change specific to just one platform, maybe that's preferable, instead of complicating the OS API.

Please let me know if you prefer me to change the singleton approach as well.

Next steps:

• I'll move the new Vector2 methods to the iOS singleton later today, and
• I'll keep the OS singleton approach for now, unless there's an explicit ask to change that.

[akien-mga]

Next steps:

• I'll move the new Vector2 methods to the iOS singleton later today, and
• I'll keep the OS singleton approach for now, unless there's an explicit ask to change that.

Sounds good to me!

I'll move the methods. But just to share my thought process - I chose adding them to the core, because the functionality itself (fitting a size inside another size given a stretch mode) is not specific to iOS. In fact, this code already exists (it is essentially what TextureRect does with its stretch modes). But since that code is located in TextureRect, I couldn't cleanly reuse it.

That's a good point. Our current guidelines would likely be to hardcode it again in iOS for now, but look later if we want to refactor and harmonize this code with a core API. We often do that to first confirm that there's a frequent need for a bit of API before solidifying it in the core.

[jkirsteins]

Pushed an update that moves the 2 methods to iOS. I also removed the tests I had added to Vector2 (they were useful to validate everything while it was WIP, but not sure they would add a lot of value in the iOS singleton).

I already squashed it, but in retrospect I realize that makes it harder to see what I changed. I'll wait for the review to be finalized next time before squashing, sorry about the inconvenience.

[akien-mga]

Looks good to me!

[Repiteo]

Thanks!