On 7/12/12 6:45 PM, Boris Zbarsky wrote:
I was talking to BenWa today, and he asked how the RCU world handles
this situation:
1) DOM update starts at time t=0
2) DOM update finishes at time t=1, schedules 4ms setTimeout
3) Layout starts at time t=1
4) Timer fires at t=5, updates DOM
5) DOM update finishes at time t=6, schedules 4ms setTimeout
6) Timer fires at time t=10, updates DOM
7) Layout from item 3 finishes at time t=11.
It seems to me like in this case the RCU setup would basically skip
painting the t=5 frame, right?
We could make it delay the t=10 frame until the layout is done instead.
But we can't make it buffer up all the frames in hopes that the slow
layout is transient, afaict. Correct?
I believe there are three options:
1. Skip the t=5 frame. Instead, at time t=5, set a "needs a new layout
once this layout is done" flag. At t=11, the DOM sees that the layout is
done, but the flag is on, so it clears the flag and spawns a new layout
task This. is what I figured would happen.
2. Delay the t=10 frame until layout is done.
3. Have a fixed number of layout tasks that are permitted to be in
flight. If a layout task is currently running on an old version but we
haven't reached our cap yet, spawn a new layout task for a new version.
This is an extension of the RCU model to some fixed number k of readers
(with K read pointers for each node). I'm not sure whether this will be
necessary, but I believe it could be done.
Patrick
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
