Timeline for multiple windows support? Any work-around in the meantime? about bevy_pixels HOT 5 CLOSED

OK, for now I'm just using a local copy of the library that passes in WindowId as a Res, rather than hard-coding it to primary. I won't submit a PR since I assume you have something more elegant in mind than that for the actual feature.

from bevy_pixels.

Go ahead and submit a PR. I'm not actively working on this, just in my free time!

from bevy_pixels.

OK, I just concluded my research. Take most of this with a grain of salt since I'm fully a Bevy-amateur.

1. Bevy multi-window support seems poor at the moment, and their multi-window example code has quite limited functionality (it only demonstrates the use of Commands, not Resources nor Components).
2. The example way to create a second window does so by adding it to an event queue (using EventWriter) such that the window itself isn't immediately available to attach the Pixels to. This is solvable, but not trivially. The two options that come to mind:
   • Hacky: the library user can just directly create the window in a startup_system using create_window like here. You'll need to ensure that this startup system runs before the "setup_system" startup system or else the window won't exist yet when you try attaching.
   • Somehow wait for the new window to be created by the winit backend EventReader, then attach the Pixels to it. I don't know enough about Bevy to know how this could work, but it might be the "right" solution.
3. PixelsResource can't be Resource anymore. You need one of them per window, but a resource is by definition globally unique. I think you would need to move to a Entity/Component-based model here, which would be a significant breaking change to your public API (but worth it IMO). Maybe there's a way to have a window entity composed of these three components: (WindowId, Window, Pixels) and then users could use the Query system to refer to which window they need at a given time.

Points 1 and 2 mean that I'm going to migrate my project from bevy/pixels to egui/winit/pixels. I might switch back once Bevy has a better multi-window solution, but I'm going to go the easier route for now.

I'll leave this issue open in case you want to use it for tracking in the future. If not, feel free to close it.

from bevy_pixels.

Thanks for doing this research @merehap.

There are some separate upstream bevy changes I'm waiting for that will likely require a large refactor of this library. Bevy 0.6 separated rendering from regular systems, but this is not exposed for plugins yet. I'm wanting to implement something like this for bevy_pixels and likely to introduce breaking changes to the API.

So given this future work I want to do (which is somewhat related to multi-window support), I'll put this issue on hold until then.

from bevy_pixels.

Hi @merehap, I've just published 0.9.0 and it now includes support for multiple windows. The multiple_windows example shows you how to use this.

from bevy_pixels.