Issues with invalidation when multiple windows are open

[cmyr]

This issue was me attempting to talk through something I'm still confused by

Edit: if anyone is curious to try and reproduce this / play around, it manifests for me in linebender/runebender#223

This is a strange issue that I do not yet fully understand. I ran into it while testing some recent runebender work on my laptop (running macOS 10.15) and I did not encounter it on my desktop, running macOS 10.14. I haven't had the chance to test elsewhere.

The problem itself is fairly simple: with multiple windows open, certain views are failing to redraw correctly; they either do not redraw at all, or they redraw partially, leaving visual artifacts:

glitch.mov

There is nothing obviously wrong; the correct paint methods are being called, for instance.

(edit: after more experimenting, it looks like invalidation is behaving differently when there are multiple windows open?)

After a bunch of experimenting, I've tracked this down to being some consequence of moving AnimFrame to be an event, and how that interacts with the normal event/update cycle. Basically: when a window receives prepare_paint, it dispatches (if needed) the AnimFrame event, and then (as with all events) does an update pass (essentially does the Widget::update method) with all windows.

There are two things I've tried that at least make the symptoms go away: the first thing is to only do update on the current window after doing prepare_paint, and the second is to move to doing our layout pass during prepare_paint, instead of during paint.

My general understanding of the problem is that update is being called on windows at an unexpected time, and this is causing weird side-effects. I think there are multiple bugs being triggered here, and in trying to track this down I've come to suspect that the current mechanism for handling animation is broken.

Some things that feel wrong:

• by sending update to other windows after prepare_paint, those windows may request additional animation frames, because they only clear their own anim_frame request flag in their own prepare_paint methods.
• we call request_anim_frame in two places: in post_event_processing (which is itself called after layout, lifecycle, and update) as well as at the end of paint.

Looking through window.rs, there are a number of other things that seem a bit iffy; it's odd that we do post_event_processing in lifecycle, for instance.

Okay, I still don't know exactly what's going on. I've thought I did, several different times. I think there are various moving parts.

My best guess, so far, is that the extra update call means that invalidate_and_finalize is always invalidating everything (because we haven't done layout yet, and needs_layout) is true) which means that we aren't correctly invalidating regions, and then hand wave somehow we aren't repainting everything?

This at least explains why moving layout into prepare_paint (where it should be anyway) fixes this; it means we skip that branch and go back to correctly handling the invalid regions.

Longer term:

This whole situation has clarified for me something I've felt for a while, which is that animation needs to be special-cased, and I will push for this change during the next major re-architecture.

What this would mean in a general sense is that the Widget should have a method that is only for handling animation ticks.

In addition to this, I suspect we should also add API in druid-shell that will let us receive regular events on each potential frame painting opportunity. This would be the mechanism that would drive animations, and we could also use this to provide a (maybe opt-in, per-window?) FrameTick event in druid; this would be useful for applications that want to do custom animation stuff, or otherwise update some state in a way that's tied to the paint timing.