We have too many layers-free things in WebRenderLayerManager. I create a new
class WebRenderCommandsBuilder and move some functions and variables from
WebRenderLayerManager to WebRenderCommandsBuilder.
MozReview-Commit-ID: BJi1E51W7ax
--HG--
extra : rebase_source : ddbfb044d467430403a3c480030ef9dec803c9f7
By returning true from WebRenderLayerManager::EndEmptyTransaction, we
avoid doing a full paint in cases where the caller decides an empty
transaction would be sufficient. WebRenderLayerManager already rejects
attempts to set some forms of empty-transaction data (specifically
transform and scroll offset updates). This means that we will never get
a call to EndEmptyTransaction where the caller is expecting a transform
or scroll offset update to be sent over to the compositor. So if we have an
implementation of EndEmptyTransaction that ignores that data, it will not
break expectations.
There is still one piece of information that WebRenderLayerManager
doesn't reject in this manner, the APZ focus state. That is, if the
layout code sets a pending APZ focus state on the WRLM, followed by a
all to EndEmptyTransaction, it expects the focus state to get propagated
to the compositor. This patch makes sure that it does happen by using
the new API added in the previous patch.
MozReview-Commit-ID: 596UgW9ZWAF
--HG--
extra : rebase_source : e0f4f201a76747d6e29cde5da26fe760fd7f770b
One of the pieces of information that can be sent to the compositor is
the APZ focus state info, which is used for keyboard APZ. This patch
adds an API that allows updating this outside of a regular WR
"transaction" (i.e. a SetDisplayList call) so that we can use it in an
empty transaction (in the next patch).
MozReview-Commit-ID: L5TCbI9FtGV
--HG--
extra : rebase_source : 427b606a333d83eb82aa566768ba331d34542e8e
Currently some callers attempt to set a "pending scroll offset update"
on the layer tree, which basically allows it to send a scroll offset
update to the compositor in an empty transaction, without doing a full
paint. However, WebRenderLayerManager doesn't really support empty
transactions yet, so we want to reject attempts to do this for now. This
will force the callers to schedule a full transaction instead of an
empty transaction.
MozReview-Commit-ID: 1bBlj59W5HH
--HG--
extra : rebase_source : 0a018989c2681b01ff325e8e2c79c9ff146f04d4
- This patch is the same as one from Bug 1382104 (Remove IsMirror concept
in favor of checking forwarder).
- It is safe to uplift this patch without the rest of Bug 1382104 as long
as the remaining Bug 1381084 is also uplifted.
MozReview-Commit-ID: 21YZObeSUa3
--HG--
extra : rebase_source : 8d543fe69f4ac9df5ccdc42d3ce47bb37eea4396
- VRManagerChild no longer needs to be a TextureForwarder
- VRManagerParent no longer descends from HostIPCAllocator or ShmemAllocator
- PVRManager no longer manages PTexture's
- VRLayerParent::mSize was not used and has been removed
MozReview-Commit-ID: 3bNN5FR5j7M
--HG--
extra : rebase_source : 634277825c00057bca6f8c77cdc942de61d61e9c
This may make the smooth scroll animation feel differently, based on zoom. I'm
not sure if the old workaround for that problem even worked; in any case, it
gave wrong values.
MozReview-Commit-ID: KXD1DPGfbgA
--HG--
extra : rebase_source : d4b4b961b90e339dabb441d9fbf2d2bcec1d04ba
Create a new type RenderDXGIYCbCrTextureHostOGL for planar-ycbcr format in WR.
That type could convert the 3 d3d11-a8 textures into gl handles. Then, WR could
draw the gl handles directly.
MozReview-Commit-ID: 1CIQO4p8u30
We currently allow the content process to shutdown the IPDL objects on
behalf the parent, and we wait for all of these instances to be freed
before we complete shutdown. This is undesirable because it requires the
parent to trust the child rather than the other way around; the child
can hold shutdown hostage by simply not releasing its instances. The
child should already support the parent closing its graphics IPDL
objects because the GPU process itself can die abruptly and be restored
at a later time.
Instead of always discarding the compositor animation id, and then
sometimes un-discarding it (which involves a linear lookup in nsTArray),
this patch now has the WebRenderLayerManager keep a set of active
animation ids, and uses that to avoid discarding the same animation
twice.
In addition, because the display item can be destroyed at any time (e.g.
in the middle of an animation), we were previously "leaking" compositor
animations in that the compositor side never got notified to discard the
IDs. This resulted in infinite composition loops. This patch solves this
problem by having any unused WebRenderAnimationData trigger discard of
the animation id during destruction. This way, even if the nsDisplayItem
is deleted in the middle of the animation we have a fallback mechanism
to discard the id.
MozReview-Commit-ID: 8G3EYHcg9Kl
--HG--
extra : rebase_source : 45e99a0d71a76a15b7fc7a0d498a6149501a722d
Sebastian Hengst
Kartikaya Gupta
Ethan Lin
Jeff Muizelaar
Kearwood "Kip" Gilbert
Bas Schouten
Cosm
Markus Stange
Boris Zbarsky
Nicolas Silva
JerryShih
sotaro
Andrew Osmond