Later patches will combine the coalescing of restyling between the
miniflush performed for animations and for transitions into a single
RestyleTracker, which will coalesce the work better. This patch changes
the API exposed for doing that so that the coalescing patch will contain
only the internals.
This affects the correctness of transitions that take over from a
running animation. (In the current code this can happen on a single
element; once the cascading changes in bug 960465 are complete it can
only happen via inheritance.)
This version of the patch changes to do the test using opacity rather
than transform, since testing using transforms encountered issues
related to bug 1031688: the presence of phantom transitions due to the
interaction of the computed value rules for transforms distinguishing
between values that the interpolation rules consider identical. (These
problems only appear after patch 24 in this bug changes the coalescing
order between a parent with animations and a child with transitions so
that the parent is handled before the child, instead of transitions
being handled before animations.)
The final two added tests fail without the patch and pass with the patch.
(With the opacity version, the third to last test also fails without the
patch, probably due to the value not having yet been sent to the layer.
This was not an issue pre-patch with the original test using transform,
though. I haven't tested that this happened with patch 0, though, so it
might have been the issue patch 0 fixes.)
This removes each test element when we're done with it so that each
successive test element isn't 100px lower. This is required to keep the
third test element (added in the next patch) onscreen when running tests
on the B2G emulator (other than when running a single test at a time).
This, in turn, is required to get animations in that test properly
shipped to the compositor thread, which is required for the test to
pass.
This patch changes JS array resizing to prefer power-of-two sized slot
requests. Previously it would mostly make slightly-more-than-power-of-two sized
requests that cause lots of slop.
Also, shrinkElements() now only does a reallocation if it would result in going
down a size class. E.g. if you pop all the elements from a 1000-element array,
it would realloc 999, then 998, then 997, all the way down the minimum size.
Now it does 512, then 256, down to the minimum size (which is 8).
I confirmed with DMD that the element allocations now have zero slop. This
reduces peak RSS loading a couple of large PDF files (four times each) with
pdf.js by 10s of MiBs.
--HG--
extra : rebase_source : c10fd4efd8ab80df5bbe14815009edb8eed3f23f
