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
On some Adreno 505 and 506 devices we are encountering driver crashes during
glLinkProgram(). The only circumstance in which we have been able to reproduce
locally is when the show-overdraw debug option is enabled. The reason appears to
be that, due to shader optimisation, the debug overdraw variants of many shaders
have identical source code. The crash seems to occur when linking a shader which
has identical source code to a previously linked shader.
This does not, however, explain the non-insignificant numbers of crashes in the
wild because a) it's unlikely many users are enabling overdraw debugging, and b)
some crash reports predate the commit which enabled shader
optimisation. However, it is possible that for a different reason we are
compiling multiple shaders with identical source code.
To attempt to work around this crash this change adds a random comment to the
end of each shader source string, on the affected devices.
Differential Revision: https://phabricator.services.mozilla.com/D83571
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
On some Adreno 505 and 506 devices we are encountering driver crashes during
glLinkProgram(). The only circumstance in which we have been able to reproduce
locally is when the show-overdraw debug option is enabled. The reason appears to
be that, due to shader optimisation, the debug overdraw variants of many shaders
have identical source code. The crash seems to occur when linking a shader which
has identical source code to a previously linked shader.
This does not, however, explain the non-insignificant numbers of crashes in the
wild because a) it's unlikely many users are enabling overdraw debugging, and b)
some crash reports predate the commit which enabled shader
optimisation. However, it is possible that for a different reason we are
compiling multiple shaders with identical source code.
To attempt to work around this crash this change adds a random comment to the
end of each shader source string, on the affected devices.
Differential Revision: https://phabricator.services.mozilla.com/D83571
This is a workaround, rather than an ideal fix. The patch contains
a comment describing why it's required and what the proper fix is.
Differential Revision: https://phabricator.services.mozilla.com/D83590
SwCompositor needs to send SWGL textures references safely to the SwComposite
thread. However, the SWGL context's texture store may grow and make accessing
these tables unsafe. To work around this, this patch adds a LockedResource
API that locks down access to these textures ahead of time both to ensure that
no table access is necessary and to help detect any unexpected modifications
of these textures while they are locked. These LockedResource objects can then
be composited safely in another thread without interfering with normal SWGL
operation in the original that that isn't simultaneously using these textures.
Differential Revision: https://phabricator.services.mozilla.com/D82666
This spawns a new SwComposite thread inside SwCompositor. Tile composite jobs
are submitted over a channel to the thread, with a condition being signaled
after all jobs are processed. The SwCompositor computes a dependency order for
the tiles based on whether it overlaps a tile that has been invalidated and
needs to be updated during the current frame. As tiles are gradually updated,
all tiles that would depend on the update as denoted by the dependency order get
submitted so that composition can proceed. Ultimately, this allows tile updates
and compositing to work in parallel, pipelining much of the cost of compositing.
Differential Revision: https://phabricator.services.mozilla.com/D82474
This restructures the WR Compositor interface a bit to support compositing
earlier in the frame. An invalidate_tile hook is added that gets called
first to signal that some picture cache tiles will be modified later in the
frame. The renderer then calls add_surface earlier before the picture cache
tiles are updated, so that any tiles that aren't invalid can proceed to
composite early before that. Finally, bind/unbind get called after so that
it can work potentially work in parallel with any tiles that are already
compositing early.
Differential Revision: https://phabricator.services.mozilla.com/D82473
I found it hard to understand the code that builds shader features,
and even harder to modify it with a new feature. This PR refactors the shader
building code by removing the macro and introducing a FeatureList abstraction, internally.
It also sorts the features on both ends (alternatively, we could use a set).
Differential Revision: https://phabricator.services.mozilla.com/D83455
With the previous change, on WebRender AnimationTransform::mTransformInDevSpace
and AnimationTransform::mFrameTransform are pretty much same, so we don't need
to set both of values, we need only mFrameTransform.
Also this patch drops move(s), I didn't know that Matrix4x4 can't be moved.
Differential Revision: https://phabricator.services.mozilla.com/D83041
This reduces the size of intern handles, which drops the size of
the PrimitiveInstance structure from 80 bytes to 64 bytes. This
has a significant performance improvement on pages with large
numbers of primitives.
It also opens up some future optimization work related to text
run interning costs, which will be a performance win on many pages.
Differential Revision: https://phabricator.services.mozilla.com/D83281
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.
Differential Revision: https://phabricator.services.mozilla.com/D83391
This reduces the size of intern handles, which drops the size of
the PrimitiveInstance structure from 80 bytes to 64 bytes. This
has a significant performance improvement on pages with large
numbers of primitives.
It also opens up some future optimization work related to text
run interning costs, which will be a performance win on many pages.
Differential Revision: https://phabricator.services.mozilla.com/D83281
Also: adjust include paths to be consistent for usages of various SVG headers,
and remove unused SVG includes (mostly for "utils" classes),
and drop stray "ns" from already-renamed SVG classes in various code comments.
Differential Revision: https://phabricator.services.mozilla.com/D83140
Previously we were calling it at 60fps for 30fps video. This meant that
any bias would be cancelled out on the vsyncs where we didn't present
anything. This also makes us match the non-WebRender path which only
calls UpdateBias after a frame has actually been drawn.
Differential Revision: https://phabricator.services.mozilla.com/D83211
Additionally, we make access to mTextureClientRecycler, mHandle and mIsAsync thread-safe as they are accessed and set from different threads
Differential Revision: https://phabricator.services.mozilla.com/D82339
When adding a text run to a batch, we split the text run in to contiguous
runs of glyphs which can be batched together. For example, when a glyph is
encountered mid-run with a different glyph format or that is cached in a
different texture, then it must be batched separately than the preceeding
glyphs.
However, even though we are only batching sub-runs of glyphs together, we use
the entire text run's bounding rect as the bounds we pass to
`set_params_and_get_batch()`. This means that each sub-run of glyphs that are
batched together will be forced to create an entirely new batch rather than
reuse an existing one (because their bounds will definitely overlap.)
This can have catastrophic consequences on performance. When the texture cache
is full enough that we have allocated a second or greater texture array, then we
risk having text runs with glyphs fragmented over different textures. This can
easily lead to thousands of draw calls on simple but text-heavy pages.
The solution is to calculate the bounds of just the sub-run of glyphs that are
being batched together, and use that instead of the text run's bounds.
Differential Revision: https://phabricator.services.mozilla.com/D83070
- WaitForBufferOwnership() must be called before locking the front buffer
- Use mDefaultFB->mFB instead of 0 to fix a freeze in the readPixels call
- SurfaceTexture.releaseTexImage must be called after each use
Differential Revision: https://phabricator.services.mozilla.com/D82944
When we request a content repaint from the controller thread, we might then
subsequently compute an apzc-to-gecko transform that expects the
mExpectedGeckoMetrics quantity to have been updated to reflect the content
repaint. However, if the content repaint got bounced to the repaint thread, that
may not have happened, if the repaint thread hasn't run yet. This is a data
race that can cause glitching in the apzc-to-gecko transform computation. This
patch addresses it by also synchronously updating the mExpectedGeckoMetrics
synchronously before bouncing to the repaint thread. The repaint thread will
re-update the mExpectedGeckoMetrics which should generally be a no-op, unless
other updates snuck in between, in which case we *do* want to do that re-update.
Differential Revision: https://phabricator.services.mozilla.com/D82762
We only use three fields from this so keeping a whole FrameMetrics around seems
heavyweight. We could even reduce it two fields by combining the zoom with the
devPixelsPerCSSPixel ratio but it seems a bit cleaner and more consistent to
do the division at the use site.
Differential Revision: https://phabricator.services.mozilla.com/D82761
This is a partial revert of bug 1647628.
The ImageBridgeChild's thread is used to dispatch synchronous tasks by its consumers.
While the background taskqueue is using a single thread threadpool, this would prevent many places to also use a background taskqueue that could end up calling the ImageBridgeChild.
Differential Revision: https://phabricator.services.mozilla.com/D82395
The goal here is to make it so that we don't special case the device on Mac
so that we can switch GPUs without needing to reset any state.
There a couple of parts to this:
1. Disable texture storage so that we can use BGRA textures and don't need swizzling.
2. Use the recommended GL_UNSIGNED_INT_8_8_8_8_REV for BGRA on desktop GL.
3. Disable swizzling.
4. Always do the PBO workaround.
Differential Revision: https://phabricator.services.mozilla.com/D82223
This should be a relatively straightforward patch. Essentially, we implement
a wrapper class (and friends) around nsZipArchive (and friends), which transparently
caches entries from the underlying zip archive in the StartupCache. This will break
without changes to the StartupCache, made in the patch after this, which allow it
to be used off of the main thread, and outside the main process.
Depends on D77635
Differential Revision: https://phabricator.services.mozilla.com/D77634
Bug 1650662 makes us RELEASE_ASSERT on FreeType initialization earlier
so I think it's unlikely that we ever hit this case in the future.
Differential Revision: https://phabricator.services.mozilla.com/D82390
This also removes the gfxDevCrashes when an invalid enum is read, because we
suspect these are mainly due to the writer shutting down mid event.
We could only crash when the writer hasn't failed, but because these reads are
in templated code it would mean updating the different event streams with a new
function. If we are still getting high numbers in the deactivation telemetry we
will need to do this to try and track down the problem.
Differential Revision: https://phabricator.services.mozilla.com/D82493
This should be a relatively straightforward patch. Essentially, we implement
a wrapper class (and friends) around nsZipArchive (and friends), which transparently
caches entries from the underlying zip archive in the StartupCache. This will break
without changes to the StartupCache, made in the patch after this, which allow it
to be used off of the main thread, and outside the main process.
Depends on D77635
Differential Revision: https://phabricator.services.mozilla.com/D77634
This should be a relatively straightforward patch. Essentially, we implement
a wrapper class (and friends) around nsZipArchive (and friends), which transparently
caches entries from the underlying zip archive in the StartupCache. This will break
without changes to the StartupCache, made in the patch after this, which allow it
to be used off of the main thread, and outside the main process.
Depends on D77635
Differential Revision: https://phabricator.services.mozilla.com/D77634
Bug 1650662 makes us RELEASE_ASSERT on FreeType initialization earlier
so I think it's unlikely that we ever hit this case in the future.
Differential Revision: https://phabricator.services.mozilla.com/D82390
The body tag has special behaviour and this page doesn't behave as one might
expect if the body tag were a div, for example. The root scroller here is still
the html element, and if the browser window is taller than 1000px it's not
considered scrollable. And on Android, with the initial-scale that gets applied,
the root scroller is actually not scrollable. This patch fixes it to ensure the
root scroller is actually scrollable in testing scenarios.
Differential Revision: https://phabricator.services.mozilla.com/D82411
Even when picture caching is disabled, we want to create the
wrapping picture elements for these slices, to simplify
some upcoming patches (we can assume that the picture cache
elements are always present).
The dynamic check at the start of FrameBuilder::build ensures
that these are pass-through pictures when picture caching is
disabled.
In future, we'll also take advantage of this to track dirty
regions in the disabled case, to allow partial present to
work in all scenarios.
Differential Revision: https://phabricator.services.mozilla.com/D82134
Previously, we would defer calculation of whether a filter was a
no-op until frame building. However, this complicates decisions
related to which clips apply to which surfaces.
Now, this decision is made during scene building. This makes things
more consistent during frame building, which we can take advantage
of in future. It also makes things like render target allocations
slightly more predictable.
Differential Revision: https://phabricator.services.mozilla.com/D82133
The machinery to report janked animations is;
1) Store the partial pre-rendered animation id and the Animation object in a
hashtable in LayerManager
2) Store the animation id in the Animation object as well
3) When we detect jank, we send the animation id to the main-thread via an IPC
call
4) Find the Animation object with the id in the hashtable and update the
Animaiton
5) Whenever the partial pre-rendered Animation stop running on the compositor
i.e. the Animation finished normally, the Animation's target element is
changed, etc. etc., remove the Animation from the hashtable
Depends on D75731
Differential Revision: https://phabricator.services.mozilla.com/D75732
The machinery to report janked animations is;
1) Store the partial pre-rendered animation id and the Animation object in a
hashtable in LayerManager
2) Store the animation id in the Animation object as well
3) When we detect jank, we send the animation id to the main-thread via an IPC
call
4) Find the Animation object with the id in the hashtable and update the
Animaiton
5) Whenever the partial pre-rendered Animation stop running on the compositor
i.e. the Animation finished normally, the Animation's target element is
changed, etc. etc., remove the Animation from the hashtable
Differential Revision: https://phabricator.services.mozilla.com/D75732
Robert Mader
Coroiu Cristina
Jonathan Kew
Butkovits Atila
Botond Ballo
Nika Layzell
Jeff Muizelaar
Kartikaya Gupta
Csoregi Natalia
Nicolas Silva
Dzmitry Malyshau
Mihai Alexandru Michis
Lee Salzman
tkhan
Emilio Cobos Álvarez
Timothy Nikkel
Glenn Watson
Andrew Osmond
Simon Giesecke
Jeff Gilbert
Markus Stange
Hiroyuki Ikezoe
Gerald Squelart
Ting-Yu Lin
Bogdan Tara
Razvan Maries
Narcis Beleuzu
Bert Peers
Jamie Nicol
Andreea Pavel
Miko Mynttinen
Sylvestre Ledru
Liang-Heng Chen
longsonr
Jean-Yves Avenard
sotaro
Daosheng Mu
Imanol Fernandez
Cosmin Sabou
Tom Prince
Doug Thayer
Bob Owen
Nick Alexander
Kagami Sascha Rosylight
aardgoose
Brindusan Cristian