Adds ImageUsageType to ImageClient and ImageContainer to identify user of Image at WebRenderImageHost.
Some ImageContainers are used only for allocating Image. Only following types calls ImageContainer::SetCurrentImages().
- ImageUsageType::Canvas
- ImageUsageType::OffscreenCanvas
- ImageUsageType::VideoFrameContainer
Differential Revision: https://phabricator.services.mozilla.com/D211147
This patch makes CanvasDrawEventRecorder track what eventCount we
recorded an external surface reference. When the reader has increment
its processedCount above that, we will release our reference as it
should have acquired a strong reference to the data. This was previously
done when we forwarded the texture, but with remote textures, we no
longer have this event. Now we check when we start a new recording, or
attempt to clear cached resources.
Differential Revision: https://phabricator.services.mozilla.com/D197216
This adds some separation between MediaInfo.h and WebRender, avoiding the
include of MediaInfo.h in WebRenderMessages.h.
Depends on D193161
Differential Revision: https://phabricator.services.mozilla.com/D193162
There are several paths in ComputeGeometryChange where we can allocate an geometry item for a filter item, but only one path that will call DetectContainerLayerPropertiesBoundsChange (which adjusts the bounds for filter items). Make sure this always happens in ComputeGeometryChange.
This was causing a bug where the geometry bounds were the full filter item height on the first paint (even though only part of the filter item was visible inside the building rect), but we did not call DetectContainerLayerPropertiesBoundsChange because it was the first paint where the filter item was visible. Then on the next paint the full filter item was visible, and there is no rect change to signal that we need to repaint.
Differential Revision: https://phabricator.services.mozilla.com/D187549
Webrender doesn't seem to handle them well. This of course will affect the balance of making things active, but hopefully this is a good trade off.
Differential Revision: https://phabricator.services.mozilla.com/D165726
WebGPU uses CompositableInProcessManager to push TextureHost directly from WebGPUParent to WebRender. But CompositableInProcessManager plumbing has a problem and caused Bug 1805209.
gecko already has a similar mechanism, called RemoteTextureMap. It is used in oop WebGL. If WebGPU uses RemoteTextureMap instead of CompositableInProcessManager, both WebGPU and oop WebGL use same mechanism.
WebGPUParent pushes a new texture to RemoteTextureMap. The RemoteTextureMap notifies the pushed texture to WebRenderImageHost.
Before the change, only one TextureHost is used for one swap chain. With the change, multiple TextureHosts are used for one swap chain with recycling.
The changes are followings.
- Use RemoteTextureMap instead of CompositableInProcessManager.
- Use RemoteTextureOwnerId instead of CompositableHandle.
- Use WebRenderCanvasData instead of WebRenderInProcessImageData.
- Add remote texture pushed callback functionality to RemoteTextureMap. With it, RemoteTextureMap notifies a new pushed remote texture to WebRenderImageHost.
- Remove CompositableInProcessManager.
Differential Revision: https://phabricator.services.mozilla.com/D164890
[Int]CoordTyped no longer inherits Units because otherwise
instances of [Int]IntPointTyped may get one Base subobject because
it inherits Units, and others because of BasePoint's Coord members,
which end up increasing the [Int]CoordTyped's objects size (since
according to the ISO C++ standard, different Base subobject are
required to have different addresses).
Differential Revision: https://phabricator.services.mozilla.com/D160713
This doesn't seem to serve any purpose anymore. MOZ_RELEASE_ASSERTing
if mBuildingRect is read during ::Paint doesn't show it happening
anywhere.
Differential Revision: https://phabricator.services.mozilla.com/D150066
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
