This adds a profiler-stats.txt file to captures that dumps the profiler
stats, if those are being recorded. They get recorded if the profiler is
visible, or if the (newly added) PROFILER_CAPTURE debug option is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D85592
This largely reverts D81868, only keeping what's needed to make SwapBuffersWithDamage
work, and also adds BufferAge support to RenderCompositorOGL.
Differential Revision: https://phabricator.services.mozilla.com/D85565
instead of using the stack for all the scene building containers,
we are making the stack explicitly, and doing all the work inside the
`build_all` function. This affects reference frames, iframes, and stacking
contexts.
Differential Revision: https://phabricator.services.mozilla.com/D85467
CLOSED TREE
We don't need these macros anymore, for two reasons:
1. We have static analysis to provide the same sort of checks via `MOZ_RAII`
and friends.
2. clang now warns for the "temporary that should have been a declaration" case.
The extra requirements on class construction also show up during debug tests
as performance problems.
This change was automated by using the following sed script:
```
# Remove declarations in classes.
/MOZ_DECL_USE_GUARD_OBJECT_NOTIFIER/d
/MOZ_GUARD_OBJECT_NOTIFIER_INIT/d
# Remove individual macros, carefully.
{
# We don't have to worry about substrings here because the closing
# parenthesis "anchors" the match.
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_TO_PARENT)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_IN_IMPL)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_IN_IMPL)/)/g;
# Remove the longer identifier first.
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_TO_PARENT//g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM//g;
}
# Remove the actual include.
\@# *include "mozilla/GuardObjects.h"@d
```
and running:
```
find . -name \*.cpp -o -name \*.h | grep -v 'GuardObjects.h' |xargs sed -i -f script 2>/dev/null
mach clang-format
```
Differential Revision: https://phabricator.services.mozilla.com/D85168
Clamp the requested XRWebGLLayer framebuffer size to ensure it's not too small to see or larger than the max native resolution.
Differential Revision: https://phabricator.services.mozilla.com/D84799
We don't need these macros anymore, for two reasons:
1. We have static analysis to provide the same sort of checks via `MOZ_RAII`
and friends.
2. clang now warns for the "temporary that should have been a declaration" case.
The extra requirements on class construction also show up during debug tests
as performance problems.
This change was automated by using the following sed script:
```
# Remove declarations in classes.
/MOZ_DECL_USE_GUARD_OBJECT_NOTIFIER/d
/MOZ_GUARD_OBJECT_NOTIFIER_INIT/d
# Remove individual macros, carefully.
{
# We don't have to worry about substrings here because the closing
# parenthesis "anchors" the match.
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_TO_PARENT)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_IN_IMPL)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_IN_IMPL)/)/g;
# Remove the longer identifier first.
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_TO_PARENT//g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM//g;
}
# Remove the actual include.
\@# *include "mozilla/GuardObjects.h"@d
```
and running:
```
find . -name \*.cpp -o -name \*.h | grep -v 'GuardObjects.h' |xargs sed -i -f script 2>/dev/null
mach clang-format
```
Differential Revision: https://phabricator.services.mozilla.com/D85168
Based on the documentation of the `offset` field in a previous patch, it
doesn't make sense to be adjusting this field when getting a new display
list. The external_scroll_offset may change, but the user-visible offset
should be preserved.
This incorrect adjustment caused the `offset` field to hold an incorrect
value in the interval between applying the new display list and re-sampling
the async scroll delta from APZ. Although this would never appear to the
user in a composited frame, hit-tests during this interval could end up
returning the wrong result.
Differential Revision: https://phabricator.services.mozilla.com/D85333
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
This is a bit of a spot fix for the specific scenario encountered. If there are
other scenarios in which we encounter a similar problem we should consider a
higher level fix.
Differential Revision: https://phabricator.services.mozilla.com/D85290
Update webrender's dependency on glslopt to 0.1.4. This includes an updated version of Mesa, which
has fixed a race condition that was causing intermittent build failures.
Differential Revision: https://phabricator.services.mozilla.com/D85254
This is meant to save us in cases where the message loop in GPU process
receives commands related to resources that point to the old EGL context
that was just shut down. Since the symbols are erased, we'd end up with
trying to execute a nullptr on `MakeCurrent()`. With marking the context
as lost, however, no symbols will be accessed.
Differential Revision: https://phabricator.services.mozilla.com/D84868
If the picture isn't a pass-through, any clips attached to it are
handled when compositing that picture into its parent. Thus, we
don't need to push those clips onto the clip stack for child
primitives.
This is probably not a noticeable performance win, but it's worth
doing to ensure it doesn't regress anything. A follow up commit will
remove the push_clip in this path completely, which will unblock
some other clip-chain optimization work.
Differential Revision: https://phabricator.services.mozilla.com/D84763
MOZ_ALWAYS_TRUE causes process abort on failure. we do not want the process abort with false.
The failure could happen when context is lost. It is not necessary to handle the context lost in RenderDXGITextureHostOGL. It is already handled by RendererOGL.
Differential Revision: https://phabricator.services.mozilla.com/D85116
This reduces IPC traffic, and avoids the (severe) impact of file access interception
and proxying by the sandbox on DirectWrite in content processes.
Differential Revision: https://phabricator.services.mozilla.com/D83240
Add a new flag for spatial nodes that identifies if the spatial
node is guaranteed to be identity (no transformation at all) for
the entirety of the scene (i.e. either a fixed identity reference
frame or a redundant scroll frame).
Although not used yet, this will be useful in future to help
remove clips during scene building that can't possibly affect
the content rendering no matter what occurs during frame building.
At the same time, port the other bool fields in spatial node into
a single bitflags.
Differential Revision: https://phabricator.services.mozilla.com/D84957
If a user clicks on a scrollbar track (but not the thumb) we start a smooth scroll animation and set the state as smooth scroll to do the page scroll, but when we receive the mouse up we clear the state even though the animation still proceeds (in most cases the animation still runs to completion fine).
Differential Revision: https://phabricator.services.mozilla.com/D84903
Just passing this along with the report is easier than
trying to store these functions some place as we do in other places.
These ops aren't used yet but will be in subsequent patches.
There's a bit of ugly around the bindings because of a cbindgen
limitation.
Differential Revision: https://phabricator.services.mozilla.com/D84916
The test is also revised to fail immediately rather than via a timeout
if the expected event is fired but targets the wrong element.
Differential Revision: https://phabricator.services.mozilla.com/D84891
This includes updates to authenticator, cubeb-coreaudio,
metal, gfx-backend-vulkan, gfx-backend-metal, freetype
libloading is duplicated because of ash
Differential Revision: https://phabricator.services.mozilla.com/D84688
Sometimes when sampling the APZC state we get a tiny non-zero async scroll
delta to be applied to the layer transform. This is not user-visible but it
does end up creating temporary surfaces in the layers code, and so is
undesirable. We can avoid this by tweaking the sampled APZC scroll offset
slightly. See comments in the patch for details.
Differential Revision: https://phabricator.services.mozilla.com/D84855
This includes updates to authenticator, cubeb-coreaudio,
metal, gfx-backend-vulkan, gfx-backend-metal, freetype
libloading is duplicated because of ash
Differential Revision: https://phabricator.services.mozilla.com/D84688
the problem was that paths that determined visibility were not switching it off
on the primitive instance. Now it's moved one level higher.
Differential Revision: https://phabricator.services.mozilla.com/D84762
This keeps us from accumulating frame buffers without bound.
Previously I was seeing as many 56 frame buffers in this list
during a tab cycling stress test.
Differential Revision: https://phabricator.services.mozilla.com/D84760
This includes updates to authenticator, cubeb-coreaudio,
metal, gfx-backend-vulkan, gfx-backend-metal, freetype
libloading is duplicated because of ash
Differential Revision: https://phabricator.services.mozilla.com/D84688
Having two classes in the inheritance chain inherit from SupportsWeakPtr
now won't compile, but you can use WeakPtr<Derived> when any base class
inherits from SupportsWeakPtr.
Differential Revision: https://phabricator.services.mozilla.com/D83674
we only draw quads, and for quads we have a fixed vertex buffer with positions.
If we get stop using instancing, we'll no longer have the luxury of 4 vertices there.
Given that they are trivial to compute, it seems simpler to just do that in the shader today.
So this PR is a required step on the way to instance-less rendering.
It appears that we are hitting a driver bug with Intel on macOS, where scissored clears don't work properly if we render without per-vertex attributes.
It doesn't make a ton of sense, but switching to quad clears appears to fix it for me. Added the corresponding entry to the wiki - https://github.com/servo/webrender/wiki/Driver-issues#bug-1652763---glitches-on-macos-intel-with-clears
Differential Revision: https://phabricator.services.mozilla.com/D83391
This patch basically attempts to make clicking in the scrollbar track outside of the scrollthumb "work". Clicking in the scrollbar track usually does a page scroll via nsSliderFrame::PageScroll. This eventually ends up in ScrollFrameHelper::ScrollBy where we turn the request from a relative one ("scroll by a page") into an absolute one ("scroll to this position").
This page scroll is typically a smooth scroll and is currently done on the main thread/layout side. Once we start scrolling the visual viewport offset with the scrollbars we can no longer do this purely on the layout side, we at least need the help of the compositor side. I think the simplest way to do this is to hand the scroll request off to the compositor and have it handle the whole thing.
Now we need to consider the following situation: user clicks scrollbar track to page scroll, smooth scroll gets partway complete on the compositor, user clicks again on scrollbar track for a further page scroll. The main thread can't send an absolute scroll offset update request to the compositor at this point because it has outdated information (it needs a 'starting position' to add the page scroll offset amount) so it'll end up scrolling to the wrong place. It has to send a relative scroll offset update.
We already have a mechanism to send relative scroll offset updates. It is implemented by sending a base scroll offset and the desired scroll offset, and then on the compositor send the difference between those two is computed and then added to the scroll offset.
This patch creates a new mechanism (so called "pure relative") that just sends a relative offset update without any absolute scroll positions. The reason I did this is because the existing relative scroll offset update mechanism is not aware of visual viewport offsets, but rather only layout scroll position. For example, here
https://searchfox.org/mozilla-central/rev/8d55e18875b89cdf2a22a7cba60dc40999c18356/layout/generic/nsGfxScrollFrame.h#446
the value we use for the base scroll offset (mApzScrollPos) is set to the layout scroll position. It may be entirely reasonable to make this existing mechanism vv offset aware, but I wanted to implement something to get it working with a smaller chance of regressions to things that already exist and work. Ideally these two mechanims would be merged.
Differential Revision: https://phabricator.services.mozilla.com/D82688
Now that layout places the scroll thumbs at the visual viewport offset instead of the layout scroll position we need to update how the compositor adjusts them.
Differential Revision: https://phabricator.services.mozilla.com/D82686
I could have use apz.allow_zooming but using a separate pref means we can flip the pref to check if the new scrollbar code is the source of a regression. Also I haven't tested the code on Fenix at all, so we can disable it there for now.
Differential Revision: https://phabricator.services.mozilla.com/D82684
This avoids creating temporary surfaces in cases where we get a transform
matrix that's not axis-aligned integers but only because of floating point
inaccuracy.
Differential Revision: https://phabricator.services.mozilla.com/D84410
Previously, scene building added all primitives to the picture tree, and then
sliced the top level picture up into picture cache slices as a post-process.
Now, primitives are added to picture cache slices as the main picture tree
is built.
In the rare case of ending up with too many picture cache slices, they
are combined into a single picture cache. This means that the common
case (the scene has a reasonable number of slices) is faster, since there
is no need to split up an array of primitives into multiple slices.
This is an optimization to scene building time, for the above reason as well
as avoiding another picture tree traversal. However, the primary benefit is
that we can know much earlier what the shared_clips are that make up each
picture cache slice. Follow up commits will take advantage of this to remove
much of the clip-chain related work that is currently done for every frame build.
Differential Revision: https://phabricator.services.mozilla.com/D84461
More leftover stuff from the document splitting effort. I'm leaving in the
corresponding APIs in webrender_api in case other consumers of WebRender
are using it.
Differential Revision: https://phabricator.services.mozilla.com/D84590
scattered GPU updates use data transfers most efficiently, since
they need a single slice of a buffer to do all the updates per frame, instead
of uploading each small section of a row independently.
Differential Revision: https://phabricator.services.mozilla.com/D78342
This makes it possible to download the capture from the artifacts of the
CI job. It would be nicer if the capture were written to a tarball/zipfile,
but having to download the files individually is better than nothing.
Depends on D84422
Differential Revision: https://phabricator.services.mozilla.com/D84423
* Use clearer pref names.
* Default (and only support) IPDL dispatching.
* Make DispatchCommands async-only.
* Sync ipdl command per sync webgl entrypoint.
* Eat the boilerplate cost, since there's not too many.
* Run SerializedSize off same path as Serialize.
* All shmem uploads go through normal DispatchCommands.
* Defer pruning of dead code for now so we can iterate quickly.
* Use Read/Write(begin,end) instead of (begin,size).
* This would have prevented a bug where we read/wrote N*sizeof(T)*sizeof(T).
Differential Revision: https://phabricator.services.mozilla.com/D81495
On WebRender there is no layer tree structures so that we can't accumulate
transform values up to the nearest APZ's scroll layer by walking up the layer
tree, or we can't tell a given transform animation is inside a perspective layer
to decide whether we need to apply the offset from the reference frame or not
[1]. So we get the accumulated transform by using
nsLayoutUtils::GetTransformToAncestor on the main-thread and inform it to the
compositor thread, and also inform the offset which is set conditionally [2]
so that we don't need to tell whether the transform animation is inside a
perspective layer or not on the compositor thread.
I am not yet 100% sure that these values are same both on WebRender and non
WebRender in all cases, once after partial pre-rendering transforms have
been used in the wild well enough and any problem has not appeared, even if
there are problems we should fix them then the non WebRender version should
eventually use this same setup instead of walking up the layer tree.
[1] https://searchfox.org/mozilla-central/rev/85ae3b911d5fcabd38ef315725df32e25edef83b/gfx/layers/CompositorAnimationStorage.cpp#273-275
[2] https://searchfox.org/mozilla-central/rev/85ae3b911d5fcabd38ef315725df32e25edef83b/layout/painting/nsDisplayList.cpp#7879-7891
Differential Revision: https://phabricator.services.mozilla.com/D83201
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
I got this wrong when I added non-WebRender support in the patch that added
the CompositionOpportunityId counter. I forgot that EndTransaction is not only
called when we composite, but also, who would have thought, when we process a
transaction.
We only want to increment mCompositionOpportunityId when we're actually about
to composite.
Differential Revision: https://phabricator.services.mozilla.com/D84111
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
There doesn't seem to be any need to have this per stacking context, as
the device pixel ratio is always the same during scene building (the
previous code just clones this object as each stacking context is
pushed).
Differential Revision: https://phabricator.services.mozilla.com/D84113
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
I got this wrong when I added non-WebRender support in the patch that added
the CompositionOpportunityId counter. I forgot that EndTransaction is not only
called when we composite, but also, who would have thought, when we process a
transaction.
We only want to increment mCompositionOpportunityId when we're actually about
to composite.
Differential Revision: https://phabricator.services.mozilla.com/D84111
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
When iterating a "built display list" the iterator expects there to be a red
zone at the end of the data buffer. The incremental display list emitter fakes
having a built display list, but it still needs to tack on the red zone to
satisfy the iterator (and assertions inside peek-poke). However we don't want
to keep this red zone there after we're done, so this patch also adds a new
method to peek-poke that strips away the red zone. The churn caused on the
vector capacity should be negligible because this churn would happen
anyway as new items are added to the display list and when the display list
is actually finalized at the end.
Differential Revision: https://phabricator.services.mozilla.com/D83788
This timestamp is provided by the system on macOS, and estimated as "the next
vsync" on all other platforms.
On macOS, the output time increments in very consistent amounts. The timestamp
is independent of when exactly the vsync callback ends up running, so it is less
vulnerable to unfortunate thread scheduling.
This makes it a more reliable source for picking video frames, for example.
Differential Revision: https://phabricator.services.mozilla.com/D83828
This ID is different from the IDs we already have:
- It is different from VsyncId because it doesn't skip numbers when composites
are delayed.
- It is different from RenderedFrameId because it also increases for no-op
composites.
- It is different from transaction IDs and epochs because it doesn't care about
the content side, it just looks at compositing.
Differential Revision: https://phabricator.services.mozilla.com/D83461
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
Similar to ANGLE and WebGL, we should be checking if there is a device
reset after a render pass via the glGetGraphicsResetStatus API.
Additionally, we should allow for simulating a device reset on platforms
other than Windows when using WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D83937
There were cases where the clip task generation considered a primitive
to be invisible, while the rest of the code proceeded with an assumption
that the clip task was created.
Differential Revision: https://phabricator.services.mozilla.com/D82121
clang may potentially insert trapping instructions when __builtin_unreachable() is used.
We need to ensure we do not use this intrinsic when asserts are disabled. To work around
this, we add a condition that is checked before entering the body of SK_ABORT.
Differential Revision: https://phabricator.services.mozilla.com/D83841
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
This ID is different from the IDs we already have:
- It is different from VsyncId because it doesn't skip numbers when composites
are delayed.
- It is different from RenderedFrameId because it also increases for no-op
composites.
- It is different from transaction IDs and epochs because it doesn't care about
the content side, it just looks at compositing.
It is currently not implemented for non-WR. In non-WR the video frame drop
detection wouldn't properly work anyway, because UpdateCompositedFrame is not
called on every composite for non-WR.
Differential Revision: https://phabricator.services.mozilla.com/D83461
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 doing a display list build, there's some code that expands the dirty
and visible rects for out-of-flow items to include the entire visual viewport
or displayport, because out-of-flow items are specially positioned in the
compositor and may become visible without the main thread knowing about it.
However, this happens even during partial updates using retained display lists,
which I believe is undesirable because the preceding non-partial update should
already have painted all the right things. The partial update should be
restricted to the part of the OOF item that actually need repainting, and the
merging of the partial update into the full display list should produce a final
display list that covers everything.
Differential Revision: https://phabricator.services.mozilla.com/D82216
The extra_data_offset wasn't being set properly in the built display list's
descriptor, so no items were being found. With that fixed it became evident
that we need to disable the display list item cache for dumping to work, since
we can't easily look up reuse items when doing the interleaved dumping. So
this patch also adds some machinery for that.
Differential Revision: https://phabricator.services.mozilla.com/D83778
1/ the texture binding expects the pixel pointer to start at the top
left of the valid rectangle, not the top left of the entire mapped
layer;
2/ pending clears must be resolved before compositing the texture;
Differential Revision: https://phabricator.services.mozilla.com/D83587
With these changes, on my Linux analysis with ClangBuildAnalyzer, the
top two expensive headers, DOMTypes.h and TabMessageUtils.h are no longer
among the 30 most expensive headers.
Differential Revision: https://phabricator.services.mozilla.com/D82935
Kartikaya Gupta
Jeremy Ir
Robert Mader
Dzmitry Malyshau
Nicolas Silva
Martin Stransky
Nathan Froyd
Imanol Fernandez
Jamie Nicol
Mihai Alexandru Michis
Jonathan Kew
Lee Salzman
Hiroyuki Ikezoe
Cameron McCormack
Markus Stange
sotaro
Timothy Nikkel
Dorel Luca
Yura Zenevich
Glenn Watson
Olli Pettay
Jeff Muizelaar
Botond Ballo
Coroiu Cristina
Butkovits Atila
Nika Layzell
Csoregi Natalia
tkhan
Emilio Cobos Álvarez
Andrew Osmond
Simon Giesecke
Jeff Gilbert
Gerald Squelart
Ting-Yu Lin
Bogdan Tara
Razvan Maries
Narcis Beleuzu
Bert Peers