Since imgFrame::Draw will limit the drawing to only look at pixels that
we have written to and posted an invalidation for, there is no need to
hold the monitor while doing so. By taking the most expensive operation
outside the lock, we will minimize our chances of hitting contention
with the decoder thread.
A later part in this series will require that a surface be freed outside
the lock because it may end up reacquiring it. In addition to the
contention win, this change should facilitate that.
Differential Revision: https://phabricator.services.mozilla.com/D7510
If we discard a frame during decoding, e.g. due to an error, then we
don't want to take that frame into account for the first frame refresh
area. We should also be handling partial frames here (the dirty rect
needs to encompass the rows that did not get written with actual pixel
data). The only place that can have the necessary information is at the
end rather than at the beginning.
Differential Revision: https://phabricator.services.mozilla.com/D7509
The clear rect and the recycle rect can overlap, and depending on the
size of the clear rect, it could be a significant amount of data that
needs to be copied from the restore frame. This patch minimizes the
copying for a row which contains both the recycle rect and the clear
rect.
Differential Revision: https://phabricator.services.mozilla.com/D7508
Given an invalidation rect, called the recycle rect, which represents
the area which may have changed between the current frame and the frame
we are recycling, we can not only reuse the buffer itself to avoid an
allocation and free, we can also avoid copying pixel data from the
restore frame which is already set.
Differential Revision: https://phabricator.services.mozilla.com/D7507
When blending full frames off the main thread, FrameAnimator no longer
requires access to the raw data of the frame to advance the animation.
Now we only request a RawAccessFrameRef for the current/next frames when
we have discovered that we need to do blending on the main thread.
In addition to avoiding the mutex overhead of RawAccessFrameRef, this
will also facilitate potentially optimizing the surfaces for the
DrawTarget for individual animated image frames.
Differential Revision: https://phabricator.services.mozilla.com/D7506
This patch adds localization for the WebReplay Jump icon, and uses
the same terminology as the one used in the context menu that triggers
the same action.
The Jump button was used in-place of the existing level icons (Error, Warning, …),
and was only displayed when the message was hovered. We now ensure the
level icon is always visible and that we only show the Jump icon when the
message is hovered.
Finally, the button was styled targeting the title attribute in CSS, which
seemed a little brittle. We now use a dedicated class which should
be safer and more future proof.
Differential Revision: https://phabricator.services.mozilla.com/D8533
--HG--
extra : moz-landing-system : lando
Now that we're outputing a stub file for each build script we can index these
commands by their output to de-duplicate them in the tup backend.
Differential Revision: https://phabricator.services.mozilla.com/D9042
--HG--
extra : moz-landing-system : lando
The output for a particular IC chain looks like this:
box2d.js:174:250 (sub) 1009 -> 772 -> (fb) 2
Which is read like this: This sub opcode has two ICs attached. The first IC was
entered 1009 times, the second 772 and the fallback stub was hit twice.
There are some conclusions we can draw from this (and some we cannot)
- We can say with confidence the fallback stub was only hit twice, meaning 99.998%
of queries to the IC chain hit in the IC rather than the fallback.
- We cannot however say necessarily that the first IC failed to provide a value
771 times.
Since new ICs are added at the front, it is possible that there was a phase
transition that happened, and the first 771 requests were served by the first
IC, followed by a transition to a new type and addition of a new IC, and
subsequently 1009 queries were served by the newly added IC.
- We can conclude with confidence that there have been at least two different ICs
involved in computation across the lifetime of the IC chain, and they are almost
equally probable.
Though we can't do temporal reasoning with entry counters, we can still do some
reasoning.
Depends on D8859
Differential Revision: https://phabricator.services.mozilla.com/D8860
--HG--
extra : moz-landing-system : lando
Instead of creating a timer and then setting the timer's target, we can
determine the timer's target and pass it in directly when the timer is
created. This reordering of steps is slightly more efficient, since
SetTarget() is both a virtual call and requires locking, both of which
can be skipped if we know the target at timer creation time. If we're
reusing the timer, we also don't need to repeatedly set the timer's
target: we can set the target once at timer creation, and then be done.
We can do this safely here because mTaskCategory doesn't change
throughout the life of the IdleTaskRunner; we make mTaskCategory `const`
to make this more explicit to the reader.
This pulls a new nom version, which is slightly unfortunate, but I do want some
of the fixes upstream, and it's build-only, so I think it's not a huge deal.
Differential Revision: https://phabricator.services.mozilla.com/D9362
