Reduce usage of `PrimaryWindow`
- Dominant language
- Rust
- Stars
- 48.2k
- Forks
- 4.8k
- Avg merge
- 3d 16h
- Merged PRs (30d)
- 171
Description
Bevy has multi-window support by modelling each window as an entity, and then (heavily handwaving) delegating to Winit for the rest. The user can then choose:
- To create two cameras for their scene, and assign it to different windows.
- To create sub-apps to get a new `World`, to allow e.g. running multiple instances of their game (not really supported yet, but I assume this is roughly how we'd go about it).
This is all great, but unfortunately, some functionality uses the `PrimaryWindow` to implement their windowing. This is basically never desired, as it locks that piece of functionality to only being available in a single window. This issue is intended to track removing instances of this, to improve multi-window support.
I've condensed the usages of `PrimaryWindow` to essentially the following:
- [ ] `bevy_render::camera::RenderTarget::normalize` should be changed to not need the primary window. Affects `bevy_core_pipeline`, `bevy_picking`, `bevy_sprite` and `bevy_ui`.
- [ ] `bevy_input_focus::InputFocus` (and possibly `InputFocusVisible`) should be made `Component`s on the window `Entity` instead of `Resource`s. Affects `bevy_winit`'s ability to update accessibility nodes.
- [ ] `bevy_text`: , seems to be a remnant of https://github.com/bevyengine/bevy/issues/5621.
A few previous efforts in this vein:
- https://github.com/bevyengine/bevy/issues/5621
- https://github.com/bevyengine/bevy/pull/10559
- https://github.com/bevyengine/bevy/issues/14945
To be clear: I'm not advocating we get rid of `PrimaryWindow`, it can be useful for the user, and it's useful for controlling the close behaviour in `bevy_window` (also discussed in https://github.com/bevyengine/bevy/issues/13698). But we should avoid using it internally in Bevy (perhaps even add it as a Clippy `disallowed-types`?).
Contributor guide
Research direction
Start with bevy_render::camera::RenderTarget::normalize and trace its effects in bevy_core_pipeline, bevy_picking, bevy_sprite, and bevy_ui. Then inspect bevy_input_focus::InputFocus and InputFocusVisible alongside bevy_winit, and review issues 5621, 14945, and pull request 10559; done means these internal paths no longer depend on PrimaryWindow while preserving its user-facing uses.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- game-dev
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100