fix: forward post_paint through Box<dyn View> - #1089
Conversation
`impl View for Box<dyn View>` forwarded `post_paint` to the inner view's `paint`, so a view wrapped in two boxes painted twice per frame, once in the paint pass and once in the post pass, and its own `post_paint` never ran. Two boxes is the common case, not the odd one: `into_any()` on an `AnyView` boxes it again, and every `Container`, `Stack` and `dyn_stack` calls `into_any()` on its children. The paint traversal dispatches on `dyn View` without the trait in scope, so a single box reaches the concrete view and hides the bug; the second box reaches the `Box<dyn View>` impl and hits it. The inspector's overlay is drawn in `post_paint`, and any custom view that draws over its children after they paint depends on the hook running. Forward `post_paint` to `post_paint`. The test paints a probe view behind one, two and three explicit boxes and counts each hook: once each, where before it was two paints and no post paint. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
@jrmoulton No problem! I actually have forked Floem because Opus/Fable have found so many bugs. I didn't want to inundate you guys with a ton of PRs. But if you're interested in it, my fork is in github.com/criccomini/floem under the |
|
If you prefer, I can submit them as PRs indidivudally as well. I just didn't want to dump them all on you uninvited... |
CI's clippy job runs on the latest stable with --deny warnings, and 1.98 flags code this branch did not touch: clippy's chunks_exact_to_as_chunks, question_mark, for_kv_map, unneeded_wildcard_pattern and unnecessary_reference lints, and rustc's float_literal_f32_fallback, which fires on every bare float passed to a setter taking impl Into<f32> (flex_grow(1.0), fr(1.)). Write those literals as f32 and apply the clippy suggestions. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
I'm short on time so I probably wouldn't be able to go through them very well anyways. but a list of bugs in a single issue would probably be a good thing if you / agent can do that.
I'm in a similar situation for my project. We're low on time but I dont think anyone involved here is opposed to AI usage so contributions (or lack) in whatever form are totally fine. What are you using floem for? |
2 participants
impl View for Box<dyn View>forwardspost_paintto the inner view'spaint:So a view wrapped in two boxes paints twice per frame, once in the paint pass and once in the post pass, and its own
post_paintnever runs.Two boxes is the common case rather than the odd one.
into_any()on anAnyViewboxes it again, andContainer,Stackanddyn_stackall callinto_any()on their children, so any child handed over as anAnyViewarrives double boxed. The paint traversal callspost_paintondyn Viewwithout the trait in scope, so a single box dispatches straight to the concrete view and hides the bug; the second box dispatches to theBox<dyn View>impl and hits it. The inspector's overlay is drawn inpost_paint, and any custom view that draws over its children after they paint depends on the hook running.This forwards
post_painttopost_paint. The new test paints a probe view behind one, two and three explicit boxes through the headless harness and counts each hook: once each with the fix, where before it was two paints and no post paint.🤖 Generated with Claude Code