Before this patch the hit test info is accumulated in the painting loop of a group, there are two issues with that:
- We can early out before getting to the painting loop if the group does not contain any visible item (hit test info items don't count as visible) so a nsDisplayCompositorHitTestInfo can be ignored if it is between two active items.
- Group boundaries should not affect the behavior of hit testing.
With this patch, hit test info is accumulated in the ConstructItem loops, is not reset in EndGroup and is carried over from a group to the next.
This means the hit test flags are extended to the scope of the svg container, I'm not entirely sure that it's correct but I believe it is at least less incorrect than the current behavior.
Differential Revision: https://phabricator.services.mozilla.com/D145358
... if the group had hit test flags set.
This is more of a workaround than a proper fix. The general idea is that if we hadn't made the item active, its bound would have included in the group's hit tested bounds. Making the item active reduces the area that is covered by hit test items and we don't want that.
***
fixup
Differential Revision: https://phabricator.services.mozilla.com/D143755
WebRender's AA doesn't look good with non-uniform scales, so we want to avoid exposing more content to it for now.
Depends on D142213
Differential Revision: https://phabricator.services.mozilla.com/D142214
Instead of reasoning about whether items should be active with a yes/no granularity, we consider whether it could/should be and have some logic to weight that against the risk of causing extra layerization when making containers active.
For example a small image *could* be made active, but we might not make it so if it causes extra layerization in cases where larger images would have been made active.
Differential Revision: https://phabricator.services.mozilla.com/D142213
WebRenderBridgeChild::GetFontKeyForScaledFont can currently cause a IpcResourceUpdateQueue race.
If we're in the middle of a transaction building a blob image, GetFontKeyForScaledFont is called
in the blob image building code using the transaction's IpcResourceUpdateQueue as expected, such
that resource updates are sent out when the transaction is finalized.
However, TextDrawTarget calls into PushGlyphs without passing along its IpcResourceUpdateQueue,
calling GetFontKeyForScaledFont without it, and causing it to immediately send out the resource
update.
So if a blob image uses a font key and submits a resource update, but a display list is built
after that also using the font key within the transaction, the display list will fail to send
the resource update because it thinks the blob image already did, even though the blob image
transaction has not yet been finalized.
The simple fix is to just pass IpcResourceUpdateQueue from TextDrawTarget into PushGlyphs, thus
ensuring the resource updates are properly ordered.
Differential Revision: https://phabricator.services.mozilla.com/D140438
It was previously only called where we create a stacking context helper: before entering the grouping code and before pushing an active item into the wr display list, and not between the active items and the next blob group. This caused the leaf clip rect of the active item to leak into the next blob group.
Differential Revision: https://phabricator.services.mozilla.com/D136906
We need them for SVG primitives.
This patch adds a bit of plumbing to disable snapping some of the primitives and forcing the antialiasing shader feature where needed, and uses it for SVG solid rectangles and images.
Differential Revision: https://phabricator.services.mozilla.com/D139024
This patch separates the tracking and submission of paint/hit-test rects, ensuring that we can remove invisible parts form the blobs without breaking hit testing.
Differential Revision: https://phabricator.services.mozilla.com/D139134
For WebGPU, we produce the textures in the compositor process and the
content process doesn't need to be that involved except for hooking up
the texture to the display list. Currently this is done via an external
image ID.
Given that WebGPU needs to work with OffscreenCanvas, it would be best
if its display pipeline was consistent whether it was gotten from an
HTMLCanvasElement, OffscreenCanvas on the main thread, or on a worker
thread. As such, using an AsyncImagePipeline would be best.
However there is no real need to bounce the handles across process
boundaries. Hence this patch which adds CompositableInProcessManager.
This static class is responsible for collecting WebRenderImageHost
objects backed by TextureHost objects which do not leave the compositor
process. This will allow WebGPUParent to schedule compositions directly
in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D138588
For WebGPU, we produce the textures in the compositor process and the
content process doesn't need to be that involved except for hooking up
the texture to the display list. Currently this is done via an external
image ID.
Given that WebGPU needs to work with OffscreenCanvas, it would be best
if its display pipeline was consistent whether it was gotten from an
HTMLCanvasElement, OffscreenCanvas on the main thread, or on a worker
thread. As such, using an AsyncImagePipeline would be best.
However there is no real need to bounce the handles across process
boundaries. Hence this patch which adds CompositableInProcessManager.
This static class is responsible for collecting WebRenderImageHost
objects backed by TextureHost objects which do not leave the compositor
process. This will allow WebGPUParent to schedule compositions directly
in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D138588
This patch ensures that we only update the external image resource for
WebGPU when there has been an actual change for the resource. In order
to guarantee this, we wait for the present to complete, and only then
issue the update. WebRenderBridgeChild::SendResourceUpdates will also
trigger a frame generation if any resources were changed, which means we
don't need to trigger a paint on the frame itself anymore.
Note that we still have a race condition when we write into the
MemoryTextureHost while in PresentCallback, and the renderer thread may
be accessing the pixel data to upload to the GPU.
Differential Revision: https://phabricator.services.mozilla.com/D138349
It's valid to move their computations before the recursion because
their inputs (the current display item and the stacking context's
deferred transform item) do not change over the course of the
recursive call.
Depends on D136827
Differential Revision: https://phabricator.services.mozilla.com/D136828
We are moving its computation before a balanced pair of
mAsrStack.push_back() and mAsrStack.pop() calls, so its
value remains the same.
Depends on D136826
Differential Revision: https://phabricator.services.mozilla.com/D136827
Previously with ImageContainers, we would put the new preferred surface
into the ImageContainer. When we check if we should invalidate, it would
have a different image key, and hence invalidate the image frame and
schedule a paint.
With ImageProviders, it returns the same key in this case, because the
ImageProvider represents a particular surface. As such, we need to
actually track when we get a substituted ImageProvider, and invalidate
the image frame more aggressively to ensure we get the preferred size.
Differential Revision: https://phabricator.services.mozilla.com/D132583
It's only meaningfully read in two places:
* WebRender fallback code.
* Some widget DEBUG-only code, which on Linux is ifdef'd and on Windows does
some rather sketchy things like sleeping for 30ms
So I think it should be ok to remove, since WR fallback has its own flashing
pref as well, IIUC.
Differential Revision: https://phabricator.services.mozilla.com/D132313
The users of this were removed with FrameLayerBuilder.
Two callers that passed true remained: one was a print
statement, and the other should be fine to change.
Differential Revision: https://phabricator.services.mozilla.com/D128946
This was added in bug 1487903 but doesn't seem to be needed anymore. The test
case from that bug still works and we now do invalidation of masks and filters
differently.
Differential Revision: https://phabricator.services.mozilla.com/D128822
This doesn't appear to be needed. If there are any invaliations
that happen inside of ConstructGroupInsideInactive they should be
overridden by InvalidateRect() for the container.
Differential Revision: https://phabricator.services.mozilla.com/D128598
Pushing the clip for the opacity item into the clip manager has a non-trivial cost, so we get better performance if we handle flattening the item before that.
Differential Revision: https://phabricator.services.mozilla.com/D125633
Pushing the clip for the opacity item into the clip manager has a non-trivial cost, so we get better performance if we handle flattening the item before that.
Differential Revision: https://phabricator.services.mozilla.com/D125633
Other items types that support flattening return false from CanHandleOpacity if their CreateWebRenderCommands implementation will fail. That's really hard to determine in advance for text, so it's simpler to just handle the opacity in the fallback path too.
Differential Revision: https://phabricator.services.mozilla.com/D125634
