Skip to content

Conversation

@srussvoll
Copy link

@srussvoll srussvoll commented Mar 20, 2025

This is the continuation of the work in

It updates the plugin to work with Bevy 0.16 (currently rc.3) and the current main branch of Iced. It also solves the following issues:

It is blocked by

Since there is no stable release of Iced with a version of wgpu that matches the version required by Bevy 0.16 this PR needs to point to a git commit for its Iced dependency.


The main change in this PR is how the loop is set up. Before this PR my understanding is that the flow would be like this (dots represent random order on runtime):

  • Convert Bevy input to Iced input
  • Update viewport
  • Process UI messages from an earlier frame
  • Draw the UI:
  1. Generate the UI based on the events gathered one or two frames ago
  2. Send UI messages based on events gathered this frame
  3. Draw the UI

Widgets implement text caching so that for instance the TextInput will now show letters that are typed for about one frame, before it disappears because the next frame is based on old state. This motivated the following new flow:

  • Convert current frame Bevy input to Iced input
  • Update viewport
  1. Send UI messages based on events gathered this frame using the UI tree from the last frame
  2. Process the UI messages
  3. Generate the UI based on the events gathered this frame.
  4. Update the UI by giving it a RedrawRequested event so that the widgets are ready for drawing.
  5. Draw the UI

Number 6 is a new step, and is required for a lot of logic happening in the widgets. This fixed the broken styling of widgets, as well as missing animations (e.g. blinking caret). In addition, to support WinitSettings::desktop_app() a RequestRedraw event is now scheduled for triggering as specified by Iced. To do this an async task is scheduled using either Tokio or async-io (smol), or using gloo-timers on the web.

Azorlogh and others added 8 commits December 8, 2024 03:39
…nking the caret/text cursor. Also added support for detecting when the window is focused/unfocused.
…r to fix the failing styling of widgets.

This is necessary because this is used by some widgets to update its per-frame state based on external state (like time). Also added a `SystemSet` to help the users ensure that the update step happens before the view step.
@Azorlogh
Copy link

Azorlogh commented Apr 8, 2025

I updated to the recent iced commits, which had some changes to the renderer: Azorlogh@3dc8f84

@srussvoll
Copy link
Author

I updated to the recent iced commits, which had some changes to the renderer: Azorlogh@3dc8f84

Thank you! Now I have updated this PR to include your recent changes.

@srussvoll srussvoll mentioned this pull request Apr 9, 2025
@tasgon
Copy link
Owner

tasgon commented Apr 10, 2025

Hey, thanks for this PR and sorry it's taken me so long to address this. So far, I've had a policy of only having versions on master that use iced and bevy versions published on Crates.io, but for the past several versions that hasn't been possible, so I'm now reconsidering my policy.

The latter problem has been solved in a fork that also includes iced-rs/iced#2693.

What additional changes are in the fork of iced? Ideally, any changes that need to be done to iced are made into pull requests against the iced repo.

@srussvoll
Copy link
Author

srussvoll commented Apr 10, 2025

Hey, thanks for this PR and sorry it's taken me so long to address this. So far, I've had a policy of only having versions on master that use iced and bevy versions published on Crates.io, but for the past several versions that hasn't been possible, so I'm now reconsidering my policy.

No problem! We're just starting to use bevy_iced at work, so I expect to find a few more things that don't currently work that have to be fixed as we start using more iced features. We can contribute with fixes for these things. I sent you an e-mail earlier regarding this. Did you get it?

Since bevy is keeping its wgpu dependency up to date new versions of bevy will not work with an old version of iced. So until the day comes where iced reaches 1.0 and starts releasing versions keeping its wgpu dependency up to date, I think we have mainly two choices. Either the users must depend on the git version of bevy_iced, or we need to get the main branch of iced published to crates.io a bit more often in some way or another.

The latter problem has been solved in a fork that also includes iced-rs/iced#2693.

What additional changes are in the fork of iced? Ideally, any changes that need to be done to iced are made into pull requests against the iced repo.

This is the fork in question: https://github.com/Argeo-Robotics/iced/tree/bevy-0.16-support
The problem is that iced is making the assumption that the renderer is not pipelined, and that does not hold for bevy_iced since bevy is using pipelined rendering. For reference, pipelined rendering means splitting the process of generating a new frame into two phases: the state update phase and the rendering phase. These can be run in parallel such that the state update phase of the latest frame is running in parallel with the rendering phase of the previous frame. In iced, there are some Arcs that are sent to the renderer as Weaks, and when Bevy runs the state update phase before the previous frame has been rendered, there is a race between using the data that the Weaks reference and the destroying of that data. That race was what caused text in the text input widget to sometimes flash when typing. The fork fixes that by replacing the Weaks with strong Arcs.

I've opened a thread in Discourse to get feedback on how to solve this. Ideally I think Iced should support pipelined rendering so that new code doesn't break bevy_iced in the future. There have been no replies to the thread yet, so I don't know how long it will take to get the fork merged back into iced. I have submitted a PR for it:

maybe it's trivial enough that it gets accepted. But still, unless iced accepts pipelined rendering support as a feature of iced, a future change may once again break bevy_iced, so it would be good to have a discussion with iced about this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants