Nearly all DisplayList objects will have their bounds queried. Currently the bounds are computed lazily in a utility dispatcher implementation DisplayListBoundsCalculator, but that code could be integrated into the Builder methods themselves to avoid the overhead of a dispatcher reading the DisplayList after it is built.

Simply avoiding the extra dispatch alone isn't a very compelling reason to integrate these mechanisms, the real benefit will come from being able to combine the logic and storage of the Builder with the Calculator. To wit:

• both save copies of the current attributes
• both have a save/restore "layer info" mechanism
• both track the transform and clip
• omission of empty operations that cover no area
• cases where understanding an op involves switching on its variations will require the same decision logic in both places (i.e. where they switch on the value of an enum parameter that defines different variations of the same general op).
• eventually we will want to take advantage of information uncovered in the bounds computations to make the DisplayLists more efficient - for instance, detecting non-trivially empty operations
• computing bounds at generation time could allow us to store the bounds for each op locally whether in the DLOp record itself or in an RTree structure which would help cull rendering faster at dispatch time - also platform embedders can benefit from a more fine-grained description of the screen coverage of the DL.
• Having bounds accumulation in the builder will allow it to expand opacity peephole coverage to a group of non-overlapping (compatible) ops. Currently it is limited to only allowing the optimization when the content is a single (compatible) op.