Add support for multi viewports and windows to UI

[oceantume]

Objective

Add support for presenting each UI tree on a specific window and viewport, while making as few breaking changes as possible.

This PR is meant to resolve the following issues at once, since they're all related.

• Resolves Support multiple UI roots #5622
• Resolves Viewport Specific UI #5570
• Resolves Support window independent UI scaling #5621

Solution

Add a new optional component that can be inserted to UI root nodes to specify which camera it should render onto. This is then used to get the render target and the viewport for that UI tree. Since this component is optional, the default behavior should be to render on the main window using the default camera. This reduces the complexity for users while giving control in contexts where it matters.

This comes with a lot of changes to the flexbox code, mainly because each node that's rendered now depends on information that's stored on its root (the scaling factor coming from the render target and viewport) which requires recursive iteration of the nodes instead of a simple query iteration.

What needs to be done to publish PR

• Decide on the final concept for the UI root component. I feel like it could replace the existing UiCameraConfig since they're similar.
• Add proper rendering support. Flexbox and input are mostly there, but a solution must be found to only render the extracted UI nodes on the wanted target. I will look into this, but may need some pointers since I'm not even sure if this is something that's supported at the moment.

Possible future improvements

• Add support for RenderTarget::Image if it's even possible and a wanted feature.

Changelog

• Adds support for selecting which window and viewport each UI tree should be presented on.

Migration Guide

UI roots (UI nodes with no parent) are now fully independent from each other in the tree. Prior to these changes, they all belonged to a common flexbox node with default Style internally. Any UI code that spawned multiple UI roots that were positioned relative to each other will need to be updated.

The simplest way to fix existing UI's in that case is to move your current root nodes to a new single root that's spawned as a transparent NodeBundle::default().

[Weibye]

Is this a design or limitation already existing or a design choice you have made?

Is there value in doing this special-casing instead of just introducing multiple taffy-trees, one for each new root?

[Weibye]

Still think this should be redesigned to use multiple trees instead

[nicopap]

Still need help with this? I finally have the opportunity to help out here.

One thing that I'd really like to start working on this is an example that uses the API with all the use cases you mention in the PR description, (no problem if it doesn't compile or crash at startup)

This way I can easily tell what is missing and from that, give pointers of where to look for to implement the missing features.

[oceantume]

I think this was in a decent place, but it definitely needs to be updated with main. I don't remember why I merged my zindex branch into this before it was merged to bevy main, maybe it was by mistake. I may have to look into fixing that because it now shows commits from that other branch as if they were part of this PR.

[oceantume]

I removed the merge with that other branch so now it's clearer what changes were made. Looking through the merge conflicts with main, there are a few things that would need to be corrected.

I think there's a conversation that needs to be resolved on how we want UI roots to relate to windows. In the current state of this PR, this is done by "linking" each UI root to a camera entity, which allows the UI code to find the target information including window, scale factor, viewport rect, etc.

I think that makes sense, but I had some concerns about having to repetitively query for the node's camera at many different points in the different UI systems (flex, render, focus) and being forced to use recursive functions with Query<&Children> everywhere to be able to keep that information around while we loop through each node hierarchy starting from its root.

Hopefully the following makes sense. I can try to explain further if not. One solution that I had in mind was to change the recently-merged UI Stack (#5877) so that it would list each UI root's stack instead of assuming that the UI is a single big stack. So the following:

#[derive(Debug, Resource, Default)]
pub struct UiStack {
    pub uinodes: Vec<Entity>,
}

Would become this:

#[derive(Debug, Resource, Default)]
pub struct UiStacks {
    pub stacks: Vec<UiStack>
}

pub struct UiStack {
    // Note that the root entity is also present in uinodes. That's because it's a logical root
    // and it's entirely possible that one of the stack's node wants a z-index that's 
    // higher or lower than its root's z-index.
    // So the utility of root here is to be able to easily query for this stack's `UiRootCamera`
    // component which is useful in many different systems (flex, rendering, focus, etc.)
    // In theory, this could also just be the camera's Entity, but root makes it more flexible
    // to create new components that can be added to a UI's root (for example a controller id)
    pub root: Entity,
    pub uinodes: Vec<Entity>,
}

Let me know what you think. If you think this makes sense and has value, it's something I'd be down to put some more time on in the next few weeks.

[nicopap]

I think we already had this discussion about what the best API for this would look like and we concluded that a link between a camera and a root was the one we should use.

Your solution is fine and more than acceptable. Even if ideally, we could encode this in the ECS. An initial element of response (although currently too limited for resolving your concerns) is #5534. Relations would also be a potential tool for this. And it's likely that once implemented, we'll have a hard time modifying it in the future.

But at the same time, we ought to ask: How large do we expect UI trees to be? Depending on the use-case it may go from about a dozen to several hundreds or thousands! Which leads me to implementation strategies that account for UI tree size and discriminate between them.

[bardt]

I recently started re-implementing ideas from this PR on the current code base. A new PR is coming some time next week, hopefully.

[tygyh]

If #10559 was a replacement for this, please close it.