search

tasgon / bevy_iced

Iced integration for Bevy
Other
125 stars 14 forks source link

Incompatibilities with Iced mainline + Renderer madness #13

Closed focustense closed 1 year ago

focustense commented 1 year ago

This isn't so much of a "bug report" as a "heads up" - the Iced maintainers have made some major changes to the repo, including shuffling around entire crates as well as some changes to wgpu. Building bevy_iced against iced master branch = epic fail.

Since I didn't see any branch here tracking the updates, I've made the required updates myself here, in case you're interested: https://github.com/tasgon/bevy_iced/compare/master...focustense:bevy_iced:iced-upgrade

However, I haven't made a formal PR because it depends on a small hack I did to downgrade iced from wgpu 0.16 back to 0.15.1. Bevy stable track is still on 0.15.1, so trying to build bevy_iced against the iced HEAD while still using Bevy stable results in dependency hell around wgpu. Obviously this is temporary, since bevy's mainline is already on wgpu 0.16, but I really didn't want to point everything including all of the bevy crates to HEAD.

Why care about mainline iced? The short answer is "gradients", although there are performance tweaks and other improvements as well.

One other change I made, which I would like to suggest you keep in some way even if you ignore/throw away the rest, is to start using iced_renderer::Renderer in the public API instead of iced_wgpu::Renderer. The former is the "backend-agnostic" version, which exposes an enum type for the backend, one of which is of course wgpu. So it's really not a big deal to use the generic renderer, as you can see from my commit, and it's important because at least some of the code in iced is designed to work with that specific generic renderer and not the Renderer trait.

_(Side note: how many types named Renderer do we really need? I was veering on table-flipping madness trying to sort through it all. But that's an iced issue, not a bevyiced issue.)

Anyway, we can (and do) kludge our way around the renderer madness for Element<...> and widget types, but some of the cool new(ish) features like canvas just won't accept the wgpu renderer, you have to give it the generic renderer. And since bevy_iced creates its own backend anyway, doesn't seem like a problem to use the generic renderer and just assume we'll have the wgpu backend when it comes time to actually render.

P.S. I also wanted to say thanks for putting this little adapter together. I'm surprised it's not more popular than it is, since in my experience, iced is the only UI library that's usable for games and is even close to being ready for prime time. I'll save my rant about the other contenders for some other time, but suffice it to say that I was feeling a little constrained by iced and spent over a week deep-diving into the alternatives, and every single one of them had major show-stopping whopper issues. Iced definitely has some rough edges and sometimes it's weird running a parallel hierarchy outside ECS and trying to shoehorn it into the ECS, but in spite of that it mostly just works, and I think I would have given up on my project a long time ago if it wasn't for iced and bevy_iced. So, thanks again, and I hope my minor contribution comes in helpful when you're ready to update.

tasgon commented 1 year ago

Thanks for the heads-up! I just switched over to iced_renderer::Renderer for the new upcoming version and it looks like everything's working.