Originally, DisplayPort suppression was a process-global static. This change makes it possible
to control DisplayPort suppression on a per-PresShell basis.
Differential Revision: https://phabricator.services.mozilla.com/D1759
Unlike GetOMTAStyle, this function returns the transform value including both
of animation and APZ values. Also this function doesn't work on WebRender.
MozReview-Commit-ID: 4zvxKebD29V
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Categories are useful to indicate: This much % of time was spent in this category.
The EVENTS category isn't a very good match for this. This category is currently
only set on labels of functions that handle the processing of an event. But
those functions are usually closer to the base of the stack, and the actual CPU
work during the processing of an event is usually in another category closer to
the top of the stack, e.g. in JS if we're running an event handler, or in LAYOUT
if we're hit testing the position of the event.
This changeset removes the EVENTS category and replaces all uses of it with the
OTHER category.
MozReview-Commit-ID: JPm5hQiBkvp
They're very similar as far as most users of the profiler are concerned, I'd
say, and I don't believe it's worth giving them two different colors in the
activity graphs.
MozReview-Commit-ID: HTqjp56naL3
Categories are useful to indicate: This much % of time was spent in this category.
The EVENTS category isn't a very good match for this. This category is currently
only set on labels of functions that handle the processing of an event. But
those functions are usually closer to the base of the stack, and the actual CPU
work during the processing of an event is usually in another category closer to
the top of the stack, e.g. in JS if we're running an event handler, or in LAYOUT
if we're hit testing the position of the event.
This changeset removes the EVENTS category and replaces all uses of it with the
OTHER category.
MozReview-Commit-ID: JPm5hQiBkvp
They're very similar as far as most users of the profiler are concerned, I'd
say, and I don't believe it's worth giving them two different colors in the
activity graphs.
MozReview-Commit-ID: HTqjp56naL3
Categories are useful to indicate: This much % of time was spent in this category.
The EVENTS category isn't a very good match for this. This category is currently
only set on labels of functions that handle the processing of an event. But
those functions are usually closer to the base of the stack, and the actual CPU
work during the processing of an event is usually in another category closer to
the top of the stack, e.g. in JS if we're running an event handler, or in LAYOUT
if we're hit testing the position of the event.
This changeset removes the EVENTS category and replaces all uses of it with the
OTHER category.
MozReview-Commit-ID: JPm5hQiBkvp
They're very similar as far as most users of the profiler are concerned, I'd
say, and I don't believe it's worth giving them two different colors in the
activity graphs.
MozReview-Commit-ID: HTqjp56naL3
For doing this, ServoComputedData is split into separate files, so that
files don't need to include ServoBindings.h just for accessing style
structs from ComputedStyles.
MozReview-Commit-ID: DPAd7PUUCl9
This patch goes through and changes a bunch of places in our tree which mention
this bug to use the new feature, making the methods more strongly typed.
There are probably more places in tree which could be changed, but I didn't try
to find them.
As suggested during the review of the original patch, we actually need to
distinguish between very recent user input (< 1 ms) and no known user input
whatsoever. Otherwise, our logic to detect URL loads via the URL bar won't work
if the user never interacted with Gecko content and only touched the native
Android UI since starting the app.
MozReview-Commit-ID: CbZNigwKcjN
updateLayerTree() is called from the callback of MozAfterPaint in
reftest-content.js all the time except when we specify reftest-no-sync-layers
or reftest-no-flush. If there is a throttled animation,
FlushPendingNotifications flushes the animation, thus it will fire another
MozAfterPaint event. It means we will end up waiting for the throttled
animation to finish. This reiteration MozAfterPaint events can be easily
observed in WebRender since WebRender fires MozAfterPaint event without
checking invalidation change. Whereas current Gecko fires MozAfterPaint only
if invalidation change happens and reftests for such throttled animations
specify the same value for 'from' and 'to' value, so it hasn't been a problem
there.
The FlushPendingNotifications in updateLayerTree() was introduced in bug
1083635 <https://hg.mozilla.org/mozilla-central/rev/5bebfbefb3c2> to
sync-decode images so it shouldn't matter if there are still throttled
animations.
MozReview-Commit-ID: B9KgNCX0kWq
Channel layout is derived by the content being played. The concept of preferred layout is meaningless. Either we have a layout defined, or we don't. There's no in-between.
So we remove it.
MozReview-Commit-ID: CSCAInNmzMS
