Feature-gate render in bevy_ui

[Niashi24]

What problem does this solve or what need does it fill?

Due to bevy_ui's dependency on bevy_render as a rendering backend which has a strong integration with wgpu, bevy_ui cannot currently support no_std. However, UI is foundational to many games, and other features of bevy_ui that would not depend on std (especially layouting) would be great to have in no_std. Rendering should be feature-gated out of bevy_ui which would allow others to develop their own platform-specific render for UI.

What solution would you like?

Add a bevy_render (or render) feature that would gate rendering integration with bevy_render behind it. This should be enabled by default.

What alternative(s) have you considered?

Break out the base UI Node and layouting systems into a separate crate (bevy_layout?) that could then be made no_std on its own. This could be confusing for people but also might be worth it if bevy_ui gets too big in the future.

Additional context

no_std support for bevy_ui is also currently blocked on no_std support for bevy_ecs and bevy_app (#15460), and a dependency with accesskit (#16312). These can be done in parallel however.

[nicoburns]

"headless" bevy_ui makes quite a bit of sense. Although the use-case I imagining is alternate renderers. I am curious which platform are you targeting that is no_std but can still render bevy?

I think if we add more feature flags to bevy_ui then we ought to add CI checks that compile the crate with those feature flags disabled. We have had recurring issues with the bevy_text feature flag breaking, and such CI checks ought to be quite fast.

[Niashi24]

I am curious which platform are you targeting that is no_std but can still render bevy?

I personally am planning on targeting Playdate, which uses software rendering and would involve either running my own software renderer on the frame buffer, or using their Sprite system.

[JMS55]

Dupe of #3815