search

dtcristo / bevy_pixels

Bevy plugin that uses Pixels (a tiny pixel buffer) for rendering
https://docs.rs/bevy_pixels
Apache License 2.0
85 stars 12 forks source link

Timeline for multiple windows support? Any work-around in the meantime? #10

Closed merehap closed 1 year ago

merehap commented 2 years ago

I noticed that multiple windows support is in the TODO list. My current project has reached the point where I need multiple window support, so I was wondering if that would be coming to this library in the near future.

Either way, is there a better work-around than just rendering the second window through a system unrelated to bevy_pixels?

Thanks for making a useful library!

merehap commented 2 years ago

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.

dtcristo commented 2 years ago

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

merehap commented 2 years ago

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.

dtcristo commented 2 years ago

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.

dtcristo commented 1 year ago

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.