`profiler_thread_is_being_profiled` is used a lot for markers, so it makes sense to have a specialized version, which is a bit shorter, and lives in ProfilerMarkers.h.
Differential Revision: https://phabricator.services.mozilla.com/D130009
`profiler_thread_is_being_profiled` is used a lot for markers, so it makes sense to have a specialized version, which is a bit shorter, and lives in ProfilerMarkers.h.
Differential Revision: https://phabricator.services.mozilla.com/D130009
It is possible that when the ImageBridge received a new image to composite, that image hasn't yet been registered via the VideoBridge.
This can happen if the decoding occurs in the different process than the content process. Even though the VideoBridge registration message was sent earlier by the RDD process, the ImageBridge message sent by the content process reached the compositor earlier.
So we only attempt to use the TextureHost if it is valid and the underlying image has been properly registered. Otherwise we will continue to use the previous image.
Some methods are modified to lazily perform their action only once the image has been registered from the PVideoBridge.
Differential Revision: https://phabricator.services.mozilla.com/D92234
The `category.WithOptions(...)` syntax was a bit strange and difficult to explain.
Now the category and options are separate parameters. Default options can be specified with `MarkerOptions{}` or just `{}`.
As a special case, defaulted-NoPayload functions don't need `<>`, and defaulted-NoPayload functions and macros don't even need `{}` for default options, e.g.:
`profiler_add_marker("name", OTHER); PROFILER_MARKER_UNTYPED("name", OTHER);`
Differential Revision: https://phabricator.services.mozilla.com/D91680
The `category.WithOptions(...)` syntax was a bit strange and difficult to explain.
Now the category and options are separate parameters. Default options can be specified with `MarkerOptions{}` or just `{}`.
As a special case, defaulted-NoPayload functions don't need `<>`, and defaulted-NoPayload functions and macros don't even need `{}` for default options, e.g.:
`profiler_add_marker("name", OTHER); PROFILER_MARKER_UNTYPED("name", OTHER);`
Differential Revision: https://phabricator.services.mozilla.com/D91680
The name `AUTO_PROFILER_MARKER_TEXT` is more consistent with the equivalent non-`AUTO` macro, and similarly arguments have been re-ordered to be the same, i.e.: Name, category&options, text.
The different macros with different argument sets can now be collapsed into one macro, and the optional arguments (timing, inner window id, backtrace) can easily be added to the `MarkerOptions` where needed.
As a bonus, a specific start time can optionally be provided at construction time.
Differential Revision: https://phabricator.services.mozilla.com/D89588
Mostly mechanical changes, with some work needed to convert the different payloads (with optional timestamps, inner window id, and/or backtrace) to the equivalent MarkerOptions.
Differential Revision: https://phabricator.services.mozilla.com/D89587
We still keep the actual biasing amount (BIAS_TIME_MS) at 1.0ms.
This makes it possible to switch from negative bias to positive bias in an
instant, at the frame that is repeated. Here's how:
While the bias is negative, it means that we're allowed to pick frames up to
1.0ms in the future. But we've drifted far enough that the next frame's
timestamp is more than 1.0ms in the future, for example 1.3ms, we cannot pick
it, so we're at a composite that repeats a frame. This is the point where we
want to switch to positive bias. In order to switch to positive bias, the next
frame's timestamp must be within the biasing threshold of the current
composition time. But if that threshold is at 1.0ms, then the 1.3ms falls
outside of that and we keep the negative bias, which is bad. With the widened
threshold of 1.5ms, we successfully switch to the positive bias in that case.
There would be no harm in keeping the negative bias if the video frames were
going to be *consistently* further than 1.0ms away from the composition time
from now on, because then even a negative bias would not make them eligible to
be picked. But whenever we have small fluctuations, which is the case when we
actually *need* the bias for consistent playback, it means that the next frame
might again be within 1.0ms of the composition time, and the negative bias would
cause a frame to be skipped.
One source of such fluctuations is the fact that WebM video frames only have
*integer millisecond* precision on their timestamps. That means they're off by
up to 0.5ms from their desired timestamp.
So the frame that's 1.3ms in the future could be one that was supposed to be at
composition time + 0.9ms, but happened to be off by 0.4ms from its desired
timestamp due to the integer millisecond restriction. This frame could then be
followed by another frame that also wanted to be at +0.9ms (compared to the next
frame's composition time), but ended up being at +0.6ms. So at that point it is
important to no longer have the negative bias, because otherwise a frame would
be skipped.
Profile before: https://share.firefox.dev/3hnOOtk
Profile after: https://share.firefox.dev/3fIfEf4
Differential Revision: https://phabricator.services.mozilla.com/D84285
Non-WebRender calls ChooseImageIndex multiple times per frame, and only calls
FinishRendering if it actually rendered the video. This makes some of the
bookkeeping here a bit annoying.
This patch introduces a behavior difference as to when mLastFrameID is updated.
It is now updated during the first ChooseImageIndex inside of a composition,
rather than from FinishRendering. But the bias is still updated from
FinishRendering. I don't think this will make an actual difference in practice.
Differential Revision: https://phabricator.services.mozilla.com/D84072
In the current state this also counts frame drops while the video is offscreen,
but this will be fixed in a later patch in the series.
This patch also adjusts the time delta check: It now compares floored milliseconds.
In 60fps WebM videos, the video frame durations are 16.0, 17.0, 17.0, 16.0, 17.0, 17.0, ...
so we need to consider frames with 16.0ms as displayable even when the target
frame duration is 16.67ms, otherwise we gloss over one third of the frames when
counting potentially dropped frames.
Differential Revision: https://phabricator.services.mozilla.com/D82635
Non-WebRender calls ChooseImageIndex multiple times per frame, and only calls
FinishRendering if it actually rendered the video. This makes some of the
bookkeeping here a bit annoying.
This patch introduces a behavior difference as to when mLastFrameID is updated.
It is now updated during the first ChooseImageIndex inside of a composition,
rather than from FinishRendering. But the bias is still updated from
FinishRendering. I don't think this will make an actual difference in practice.
Differential Revision: https://phabricator.services.mozilla.com/D84072
In the current state this also counts frame drops while the video is offscreen,
but this will be fixed in a later patch in the series.
This patch also adjusts the time delta check: It now compares floored milliseconds.
In 60fps WebM videos, the video frame durations are 16.0, 17.0, 17.0, 16.0, 17.0, 17.0, ...
so we need to consider frames with 16.0ms as displayable even when the target
frame duration is 16.67ms, otherwise we gloss over one third of the frames when
counting potentially dropped frames.
Differential Revision: https://phabricator.services.mozilla.com/D82635
Correctly indicate that we're not in a composition during SetDisplayList or
during empty transactions, by making sure the composition timestamp is null
outside of a composition.
We also now return 0 rather than -1 from the first call to ChooseImageIndex
outside of a composition, so that static images (like canvases) default to
the correct initial frame. We don't call ChooseImageIndex for them again once
we composite them.
This is different from non-WebRender, which would call ChooseImageIndex on
canvas layers during every composition.
This introduces a behavior difference for static images when WebRender is enabled:
Those images will no longer update mLastFrameID, because UpdateCompositedFrame
will not be called during a composition for them.
I'm also removing a comment that seems like it's unnecessarily duplicating
information from another comment a few lines further up. That other comment is
also easier to understand.
Differential Revision: https://phabricator.services.mozilla.com/D83460
This also makes it so that UpdateBias for non-WebRender is only called when the
video frame changes. This mirrors the recent change that we made for WebRender
in bug 1652181. Non-WebRender only calls UpdateCompositedFrame when it actually
draws the video onto the screen, so when the video is the only thing that was
updating, the new behavior is equivalent. But the new behavior makes more sense
if you have a 30fps video and a 60fps animation running on a 60fps screen at the
same time - now the bias won't be accidentally reset every other frame.
Differential Revision: https://phabricator.services.mozilla.com/D83459
This currently only works for WebRender. In non-WR, no frame drops are reported.
There are two reasons why it doesn't work for non-WR:
- Non-WR currently does not increment the composition opportunity ID.
- In non-WR, UpdateCompositedFrame is only called for videos when they are
drawn. But this detection relies on it being called on every composite, if
the video is part of the on-screen scene. (WR does that.)
To make this detection work for non-WR as well, we would need to address both
of those points. The latter point is somewhat tricky because non-WR calls
ChooseImageIndex many times throughout a composite, and we would need to choose
a point in the composite at which to "lock in" the image for that composite and
cache the image index on the ImageHost somewhere, and then also find a way to
reset that locked-in index in the next composite. I haven't come up with a way
to do that and I do not know if it is worth the effort.
Differential Revision: https://phabricator.services.mozilla.com/D83463
In the current state this also counts frame drops while the video is offscreen,
but this will be fixed in a later patch in the series.
This patch also adjusts the time delta check: It now compares floored milliseconds.
In 60fps WebM videos, the video frame durations are 16.0, 17.0, 17.0, 16.0, 17.0, 17.0, ...
so we need to consider frames with 16.0ms as displayable even when the target
frame duration is 16.67ms, otherwise we gloss over one third of the frames when
counting potentially dropped frames.
Differential Revision: https://phabricator.services.mozilla.com/D82635
Correctly indicate that we're not in a composition during SetDisplayList or
during empty transactions, by making sure the composition timestamp is null
outside of a composition.
We also now return 0 rather than -1 from the first call to ChooseImageIndex
outside of a composition, so that static images (like canvases) default to
the correct initial frame. We don't call ChooseImageIndex for them again once
we composite them.
This is different from non-WebRender, which would call ChooseImageIndex on
canvas layers during every composition.
This introduces a behavior difference for static images when WebRender is enabled:
Those images will no longer update mLastFrameID, because UpdateCompositedFrame
will not be called during a composition for them.
I'm also removing a comment that seems like it's unnecessarily duplicating
information from another comment a few lines further up. That other comment is
also easier to understand.
Differential Revision: https://phabricator.services.mozilla.com/D83460
This also makes it so that UpdateBias for non-WebRender is only called when the
video frame changes. This mirrors the recent change that we made for WebRender
in bug 1652181. Non-WebRender only calls UpdateCompositedFrame when it actually
draws the video onto the screen, so when the video is the only thing that was
updating, the new behavior is equivalent. But the new behavior makes more sense
if you have a 30fps video and a 60fps animation running on a 60fps screen at the
same time - now the bias won't be accidentally reset every other frame.
Differential Revision: https://phabricator.services.mozilla.com/D83459
When user adjusts the video playback rate, which might cause we sending images in a speed that is faster than the speend we composite images.
In this situation, the frame dropping actually won't cause any visual defect and we also don't want to report this frame dropping to user, because it's not caused by system overloading, it's just our compositor doesn't support compositing images in such a high rate.
Therefore, we should check if the dropped images are caused by system overload or high update rate, and only report the former to user.
Differential Revision: https://phabricator.services.mozilla.com/D46236
When user adjusts the video playback rate, which might cause we sending images in a speed that is faster than the speend we composite images.
In this situation, the frame dropping actually won't cause any visual defect and we also don't want to report this frame dropping to user, because it's not caused by system overloading, it's just our compositor doesn't support compositing images in such a high rate.
Therefore, we should check if the dropped images are caused by system overload or high update rate, and only report the former to user.
Differential Revision: https://phabricator.services.mozilla.com/D46236
We can't rely on the FrameID continuity to determine if a frame has been dropped due to timing or not.
The reason being that the VideoSink will not send to the compositor frames it knows as being late already (causing a discontinuity in the frames IDs), and count them as being dropped.
If we were to look at discontinuity on the compositor we would account for those frames twice.
FramesID will also increase non-linearly if a frame isn't painted because it's not visible (either out of the visible tree or in a hidden tab).
What we can measure however, is when a frame should have been painted but didn't because it was too late by looking at the value returned by ImageComposite::ChooseImageIndex() or when a new set of images is being received by the ImageComposite.
Any images found in the earlier array but never returned must have been dropped due to timing.
Looking at the index continuity greatly simplify the logic as we no longer need to worry if a video is hidden or not, or be part of a layer that is itself hidden as neither SetImages will be called then, nor ChooseImage
For now, we only account for those frames dropped, and do not report them yet.
Differential Revision: https://phabricator.services.mozilla.com/D2176
We will use the characteristic of which TimedImage is returned to keep track on how many frames were dropped because they were too old. As such, we must make sure the retrieval of the current image is serialised.
This allows to reduce duplicated code between WebRenderImageHost and ImageHost classes.
Additionally, make RenderInfo::img member const as really, we never want to modify that one.
A future change will enforce that RenderInfo.img never survives longer than the ChooseImage()'s caller to clarify the lifetime of the TimedImage.
Differential Revision: https://phabricator.services.mozilla.com/D2175
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: 77D61xpSmIl
