Reactive Rendering - #2662
Merged
Merged
Reactive Rendering#2662
Conversation
hecrj
added
feature
... and fix the redraw queue logic in `iced_winit`.
If we do not request it, macOS does not get any `RedrawRequested` events. Shouldn't `winit` [take care of this]? Probably a bug. [take care of this]: https://docs.rs/winit/0.30.5/winit/event/enum.WindowEvent.html#variant.RedrawRequested
hecrj
force-pushed
the
reactive-rendering
branch
from
November 5, 2024 22:53
d371feb to
03bffe3
Compare
4 tasks
|
I see this PR from the latest 0.14 release, but may I see a document about the feature? this is a quite big feature. |
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR changes the runtime to only perform a redraw of the user interface when either an
updateoccurs, or a widget explicitly requests it.Currently,
icedrenders all the time unconditionally on every runtime event. Effectively, this means that when you move your mouse around in anicedapplication, the runtime can easily draw hundreds of identical frames—wasting plenty of resources.The changes here make both the runtime and the built-in widgets aware of their last status when drawn, and only request a redraw when needed. This should normally translate to a lower CPU and (specially) GPU usage when interacting with most applications.
As a consequence, the
WidgetandOverlaycontract now require implementors to explicitly request redraws when necessary. Most of the time, this entails some kind of "diffing" during event processing to figure out if the widget state has changed.This new feature is enabled by default but, since it makes widget implementation more difficult and may not make sense for highly dynamic applications, a user can opt out by enabling the
unconditional-renderingfeature; which restores the old behavior.Related important breaking changes include:
Widget::on_eventdoes not return anevent::Statusanymore. Instead, a widget can capture an event by callingShell::capture_event. Since widget logic is generally quite imperative, this paradigm fits better and is also more consistent with other shell-related logic.Widget::on_eventhas been renamed toupdate.Programboth forcanvasandshadernow return awidget::Action, which can be leveraged to either publish a message or request a redraw, and also event capturing.Eventtypes forcanvasandshaderhave been removed. They now simply use the foundationalcore::Eventtype.