Bugzilla

I did a bit of random browsing (various canvas demos/tests, and some Google Docs) with an instrumented build, and found that in the overwhelming majority of instances, we only ever append one element to this array. So yes, we should try to eliminate that allocation.

Rather than an AutoTArray, where we'll end up using LastElement() as the "current" state -- which means every access has to look up the array length and use it as an index -- maybe we should store a ClipState directly in the ContextState, along with an auxiliary (non-auto) array, usually unused, to push any saved states to. The overall footprint of that should be comparable to a 1-element AutoTArray, but with optimized access for the current state.

I did a bit of random browsing (various canvas demos/tests, and some Google Docs) with an instrumented build, and found that in the overwhelming majority of instances, we only ever append one element to this array. So yes, we should try to eliminate that allocation.

Rather than an AutoTArray, where we'll end up using LastElement() as the "current" state -- which means every access has to look up the array length and use it as an index -- maybe we should store a ClipState directly in the ContextState, along with an auxiliary (non-auto) array, usually unused, to push any saved states to. The overall footprint of that should be comparable to a 1-element AutoTArray, but with optimized access for the current state.

[edit: After looking over the code, I don't think that's worth doing, as our usage patterns mostly aren't focused on just accessing the "current" (last) element but on iterating over the states. So the simple AutoTArray approach makes most sense here.]