This patch ensures that we push clips in WR for each display item,
reflecting the display item's clip chain as computed in Gecko. A display
item will often share part or most of its clip chain with other display
items, so we try to reuse the corresponding WR clip ids as much as we
can instead of defining new duplicated clips.
MozReview-Commit-ID: LkBh8LIpQ4J
--HG--
extra : rebase_source : 5af1de0931f1d059e98b5c66b15988961503e114
This regenerates the cargo lockfiles and FFI bindings header. It also revendors
the third_party/rust libraries.
MozReview-Commit-ID: ID0YhoIH6cz
--HG--
extra : rebase_source : 7c22828a831eafcf527f2c3baf8d4d012db8f9a4
Previously, the WebRenderBridgeParent for each content layer tree would use the
same WebRenderAPI instance as the top-level WebRenderBridgeParent for that window.
However, in order to make the namespacing changes work we now need to use a
separate WebRenderAPI instance for each WebRenderBridgeParent. The content
WebRenderAPIs are cloned from the parent one, so that they all share the same
backend, but can allocate resource IDs in distinct namespaces.
MozReview-Commit-ID: 7VTFL8F09n7
--HG--
extra : rebase_source : 2da1d03abc23bd7852e4b12fe133889bd80cad53
In theory the upstream API change should allow us to share the same WR renderer
instance across multiple WebRenderAPI instances. For now however I retain the
existing behaviour of one WR instance for each WebRenderAPI instance, but keep
track of the document id in a new DocumentHandle struct. The C++ side keeps
a pointer to this DocumentHandle struct instead of the raw RenderApi.
MozReview-Commit-ID: I9pCKOY1OYx
--HG--
extra : rebase_source : 7b0ae2ccb2692a76045371ac165468c7f7539b40
There's no real reason to restrict this to LayerSize, since we use
use Layer and LayoutDevice coordinate spaces interchangeably for
webrender. With the templating of the function the compiler doesn't know
what type to use for {0, 0} so I added a new function to deal with that.
MozReview-Commit-ID: BA83Sy9UjYH
--HG--
extra : rebase_source : 15e5b31d0275628713c5eb584d622d22485dfda9
There's no real reason to restrict this to LayerSize, since we use
use Layer and LayoutDevice coordinate spaces interchangeably for
webrender. With the templating of the function the compiler doesn't know
what type to use for {0, 0} so I added a new function to deal with that.
MozReview-Commit-ID: KyabB6P6LiA
--HG--
extra : rebase_source : d5fff8f21a17c433d3c8c580fdd3153140d61545
With DXVA2 hardware-video-decoding, the RendererOGL should have a
synchronization mechanism to prevent the flickering of video texture.
Create a SyncObject in RendererOGL to do the texture synchronization.
The WebRenderAPI also exposes the RendererOGL's SyncHandle to
WebRenderBridgeParent. Then, the WebRenderBridgeParent could pass this SyncHandle
to the video decoding module for texture synchronization.
MozReview-Commit-ID: toQ2mO5fzG
Create the corresponding RenderTextureHost type and WR commands for DXGI texture type.
The DXGITextureHostD3D11 will use 1 or 2 image keys for non-nv12 and nv12 texture format.
The DXGIYCbCrTextureHostD3D11 is a special case. The WR uses ANGLE in windows platform,
but the ANGLE doesn't support A8 format directx texture directly. So, we use libyuv to
convert the DXGIYCbCrTextureHostD3D11 texture buffer into RGBA format buffer and use
WR::AddImage() for that image. This is a slow code path. We will refine this case later.
The whole RenderD3D11TextureHostOGL implementation is in the next patch.
MozReview-Commit-ID: F4mPCALj1OY
This commit organizes the structs in bindings.rs to be sorted by similarity.
MozReview-Commit-ID: KIskAwDiJIc
--HG--
extra : rebase_source : 2854f8d7f3a60fee6e2136db6b1a91c9c7dc0e24
This change preserves the existing semantics of the webrender_bindings code,
although it may result in creating unnecessary clips. A follow-up bug will be
filed to make clip optional in the C++ interface, and avoid passing it in places
where it is not necessary.
MozReview-Commit-ID: KMeBumpgDXL
--HG--
extra : rebase_source : 9ec04e1e8f0b985532908460958f30ed42e220bd
