Support for (de)serializing measure funcs
Summary: In addition to all the state that gets set on the node that is easy to serialize - like floats, enums, bools, etc - we also need to serialize measure functions. This is because these functions take a nontrivial amount of time up during layout and we should capture that. Also, they are important to the ability to truly replay layout as it was captured as the results of the measure functions determine many of the steps the layout algorithm takes. Capturing this is rather tricky however, but I think I found a solution that is relatively simple and non-error prone. Essentially, since we are capturing the entire tree and virtually every input that goes into the flexbox algorithm, we *should* be able to replay layout exactly as it was captured. This means that the order in which measure functions are called *should* be the same. If this is the case, then all we need to do to capture the measure functions is store their input, output, and duration in a big array. During deserialization we just keep track of an index and use that to determine which measure function we should call. That is the premise behind what happens in this diff. In theory the algorithm could change and the capture would be wrong but it is easy enough to recapture again. Additionally we need to dirty the tree so that we get rid of caching which might omit some measure func calls In order to capture you need to insert a method exposed by CaptureTree.h into the client measure func, which is kind of annoying but not that bad. In future diffs I will put a macro in place to make this even easier. I also add our first capture! Which is of a large react native desktop app Reviewed By: NickGerleman Differential Revision: D53581121 fbshipit-source-id: 876a230208d67f0ecf76844a4f1b80048353aae2
This commit is contained in:
committed by
Facebook GitHub Bot
parent
cc66362a28
commit
e2ed3f031d
24109
benchmark/captures/chat-mac.json
Normal file
24109
benchmark/captures/chat-mac.json
Normal file
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user