The background pass (construct_blocks_in_background()) builds every block not yet built, and holds until every required block is painted (required_fulfilled()), which builds dock's view model into core. The construct component, meanwhile, builds every id it names in the flush that applies it, so a caller that wants pacing has to split its request across payloads.
Make construct the way to ask for construction in order: core queues the ids as given and builds them one per idle tick, after whatever evaluation needs, at the pace of background_construction_delay. The background pass and required_fulfilled() go. A front-end decides when to send its next request: dock asks for the active view, then for the other views once it has painted them, and core's own UI asks for its open stacks, then the collapsed ones. A board no front-end gates still builds every block, since every block is needed there.
Spec: https://github.com/orgs/BristolMyersSquibb/discussions/489
The background pass (
construct_blocks_in_background()) builds every block not yet built, and holds until every required block is painted (required_fulfilled()), which builds dock's view model into core. Theconstructcomponent, meanwhile, builds every id it names in the flush that applies it, so a caller that wants pacing has to split its request across payloads.Make
constructthe way to ask for construction in order: core queues the ids as given and builds them one per idle tick, after whatever evaluation needs, at the pace ofbackground_construction_delay. The background pass andrequired_fulfilled()go. A front-end decides when to send its next request: dock asks for the active view, then for the other views once it has painted them, and core's own UI asks for its open stacks, then the collapsed ones. A board no front-end gates still builds every block, since every block is needed there.Spec: https://github.com/orgs/BristolMyersSquibb/discussions/489