Implement update_anim pass #539

PoignardAzur · 2024-08-24T17:21:36Z

This is part of the Pass Specification RFC: linebender/rfcs#7

DJMcNab

Any examples using animation just doesn't work in this PR...

We could also use a link to linebender/rfcs#7 in this PR's description

DJMcNab · 2024-08-26T10:17:24Z

masonry/src/render_root.rs

-                if root_state.request_anim {
-                    root_state.request_anim = false;
-                    self.root_lifecycle(LifeCycle::AnimFrame(elapsed_ns));
+                if root_state.needs_anim {


I wonder if this check should be inside run_update_anim_pass. I can understand why it isn't with post_event_processing, but my understanding is that that will be removed?

I need to write down my thoughts on this (and correct the RFC); The short version is that update_anims doesn't really have the semantics of a "rewrite" pass. It's more of a special event pass.

Re-reading your question again, I realize I misunderstood it. You're right that the check is a bit superfluous. The pass already does it once per widget anyway.

DJMcNab · 2024-08-26T10:22:59Z

masonry/src/passes/update.rs

+    state.item.needs_anim = false;
+    state.item.request_anim = false;


It's not clear to me why this code is here.
Currently, this stops any animation after one frame, if it requests a new frame in the handler.

What is the expected behaviour if an animation wants to last more than one frame?

Yeah, I think I rushed this PR too much.

PoignardAzur · 2024-08-30T11:33:23Z

New version, which I've tested with the variable clocks example. Everything works fine now.

Philipp-M

Code looks good to me, I can't really test this on my ultra-old Notebook, which doesn't seem to support Vulkan properly. Though I get a panic in parley which seems weird to me (as unrelated to Vulkan I guess)? Anyhow this is not related to this PR as I also get this on main.

Philipp-M · 2024-09-01T12:53:01Z

masonry/src/contexts.rs

+        self.widget_state.needs_anim = true;
        self.widget_state.request_anim = true;


I guess we want to either rename the needs_... variables to be more clear, or document the difference between request_... and needs_... well.

At a first glance, the naming suggests a little bit redundancy here, at least it wasn't clear to me what the difference exactly should be.
(But I don't think that this should be done in this PR, and it's probably better to be consistent with the rest of the naming).

I guess we want to either rename the needs_... variables to be more clear, or document the difference between request_... and needs_... well.

Right now the fields all have doc comments that follow this pattern:

request_xxx: "This widget explicitly requested XXX"

needs_xxx: "This widget or a descendant explicitly requested XXX"

Once we do a documentation pass I'll explicitly note the pattern as well, at least in WidgetState and ARCHITECTURE.md. If you think there's other places we could cover, I'm interested. This is the sort of pattern where you want redundancy in documenting it.

Although note that it's strictly an internal naming convention that library users won't be exposed to, so it limits the places we're likely to document it in.

I do like those names. I think they're concise, which is valuable, and the "request/needs" difference feels to me like it's easy to remember once it's been explained.

DJMcNab

This still doesn't work as expected, unfortunately.

DJMcNab · 2024-09-02T15:50:52Z

masonry/src/passes/update.rs

+    state.item.needs_anim = false;
+
+    if state.item.request_anim {
+        state.item.request_anim = false;


Maybe we should have a comment here that most passes reset their needs and request after the call to the widget method, but that it's valid and expected for request_anim to be called in response to AnimFrame.

DJMcNab · 2024-09-02T15:54:27Z

masonry/src/render_root.rs

+                let mut root_state = self.widget_arena.get_state_mut(self.root.id()).item.clone();
+                self.post_event_processing(&mut root_state);
+
+                self.last_anim = Some(now);


I don't think this will have the behaviour we want. Consider for example:

diff --git a/xilem/examples/variable_clock.rs b/xilem/examples/variable_clock.rs index 8bead4d80..ea7dd599f 100644 --- a/xilem/examples/variable_clock.rs +++ b/xilem/examples/variable_clock.rs @@ -60,7 +60,7 @@ fn app_logic(data: &mut Clocks) -> impl WidgetView<Clocks> { }; } }, - |data: &mut Clocks, ()| data.now_utc = OffsetDateTime::now_utc(), + |data: &mut Clocks, ()| data.weight = (data.weight + 100.) % 1000., ), ) }

This will not animate smoothly, but will instead to jump to the full value, because when the animation frame occurs, the time will be the time since the last frame, rather than 0 as it is before this PR.

Would you mind taking responsibility for this PR, then? It seems like this is more in your wheelhouse than mine, if you're currently working on frame pacing.

Can do. I think this only needs a very small change to be ready to land.

…ates

PoignardAzur · 2024-09-09T13:39:11Z

I'm going to do a small tweak on your changes, pushing now.

Outdated

PoignardAzur · 2024-09-10T11:20:19Z

I think this is ready to merge, it's on the critical path, and Daniel's concerns are essentially addressed.

I think Phillip is still on vacation and isn't going to review this week. Either way, unless a blocker comes up, I'll merge this tomorrow.

DJMcNab · 2024-09-10T12:15:00Z

masonry/src/widget/widget_pod.rs

            // Routing DisabledChanged has been moved to the update_disabled pass
            LifeCycle::DisabledChanged(_) => false,
+            // Animations have been moved to the update_anim pass
+            LifeCycle::AnimFrame(_) => false,


Is this unreachable!?

Not quite. A container widget could request anim. If it recurses the lifecycle function over children, then that line of code is reached.

Hmm. Is it meaningful for it to be reached?
That is, should we put a debug_panic here? Is it ever sensible to send a different lifecycle event to the one you received down the tree.

I wouldn't bother. This code is going away anyway.

PoignardAzur force-pushed the implement_pass_spec_update_anim branch from eea9ac3 to 89e2a17 Compare August 24, 2024 17:22

DJMcNab reviewed Aug 26, 2024

View reviewed changes

Philipp-M approved these changes Sep 1, 2024

View reviewed changes

DJMcNab previously requested changes Sep 2, 2024

View reviewed changes

PoignardAzur added 3 commits September 9, 2024 14:28

Implement update_anim pass

8af2099

Fix anim code

df70c7b

Add internal comment

531ac4b

PoignardAzur force-pushed the implement_pass_spec_update_anim branch from be909ac to 531ac4b Compare September 9, 2024 12:28

Adjust handling of animation to properly account for intermittent upd…

9cf8ea5

…ates

DJMcNab requested a review from Philipp-M September 9, 2024 12:57

Consistently use the same order for needs_layout and request_layout

674266e

Tweak anim timing code.

48def58

PoignardAzur requested review from DJMcNab and removed request for DJMcNab September 9, 2024 14:40

DJMcNab approved these changes Sep 10, 2024

View reviewed changes

PoignardAzur added this pull request to the merge queue Sep 12, 2024

Merged via the queue into main with commit 2fa8a05 Sep 12, 2024
17 checks passed

PoignardAzur deleted the implement_pass_spec_update_anim branch September 12, 2024 11:13

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement update_anim pass #539

Implement update_anim pass #539

PoignardAzur commented Aug 24, 2024 •

edited

Loading

DJMcNab left a comment •

edited

Loading

DJMcNab Aug 26, 2024

PoignardAzur Aug 26, 2024

PoignardAzur Aug 30, 2024

DJMcNab Aug 26, 2024

PoignardAzur Aug 26, 2024

PoignardAzur commented Aug 30, 2024

Philipp-M left a comment

Philipp-M Sep 1, 2024

PoignardAzur Sep 9, 2024

DJMcNab left a comment

DJMcNab Sep 2, 2024

PoignardAzur Sep 9, 2024

DJMcNab Sep 2, 2024

PoignardAzur Sep 9, 2024

DJMcNab Sep 9, 2024

PoignardAzur commented Sep 9, 2024

PoignardAzur commented Sep 10, 2024

DJMcNab Sep 10, 2024

PoignardAzur Sep 10, 2024

DJMcNab Sep 10, 2024 •

edited

Loading

PoignardAzur Sep 10, 2024

		state.item.needs_anim = false;
		state.item.request_anim = false;

		self.widget_state.needs_anim = true;
		self.widget_state.request_anim = true;

Implement update_anim pass #539

Implement update_anim pass #539

Conversation

PoignardAzur commented Aug 24, 2024 • edited Loading

DJMcNab left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PoignardAzur commented Aug 30, 2024

Philipp-M left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DJMcNab left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PoignardAzur commented Sep 9, 2024

PoignardAzur commented Sep 10, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DJMcNab Sep 10, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PoignardAzur commented Aug 24, 2024 •

edited

Loading

DJMcNab left a comment •

edited

Loading

DJMcNab Sep 10, 2024 •

edited

Loading