Reland "Remove pipeline in favor of layer tree holder" #24947
Conversation
…flutter#18901)" (flutter#24387)" (flutter#24456)" This reverts commit 04afdad.
iskakaushik
force-pushed
the
reland-pipeline
branch
from
28603f1 to
999a15e
Compare
chinmaygarde
left a comment
chinmaygarde
left a comment
There was a problem hiding this comment.
I specifically reviewed 28603f1. I believe the rest was identical to the reverted patch.
|
@iskakaushik This removed the PipelineItem flow that DevTools was using to detect the duration of a frame as it was being serviced on the two threads. I think we can recreate the flow in this new mechanism. Can we revert it (sadly, once again) and add that flow to unblock DevTools or do you want to fix forward by adding the flow? |
|
Yup, will revert it. I want to debug flutter/flutter#78257 (comment) as well so maybe two birds with one stone. Though this particular stone (reverting this change) has been used multiple times. |
|
Right, subtle changes to scheduling are no fun to push through. We need to tackle flutter/flutter#27609 correctly anyway. Right now, I doubt we have the bandwidth to create a test harness that allows us to reason about frame scheduling and trace emission. |
|
Are they prepared for flows that start and never end? Should we establish a "flow aborted" event that they can look for to see when frames are dropped on the floor? |
Likely not. The current behavior is to "end" flows that are being prematurely terminated. That is, there is no difference between a successful or unsuccessful flow. But it always ends. |
|
It looks like there already were existing ways to prematurely end flows before so this should be no different - but it will be more common. We might want to ask them if they'd like a way to distinguish dropped frames from completed frames now that they will be more common. |
4 participants
This reverts commit 04afdad.
This had to be reverted because of flutter/flutter#76216. This has been fixed in 28603f1.