ImageBridgeChild has only one global TextureFactoryIdentifier. When WebRender is enabled, it is used for both WebRender widget and non-WebRender(BasicCompositor) widget. WebRenderImageHost and ImageHost are incompatible and WebRenderTextureHost does not permit to be consumed on compositor thread. Then it does not work well for non-WebRender widget. To address the problem at ImageContainer, ImageContainer needs to know a connected widget type. It is not easy in some cases like WebRTC. Then host side could address the problem easier.
CompositableParentManager::FindCompositable() is changed to permit transform from WebRenderImageHost to ImageHost if it is necessary when WebRenderImageHost belongs to ImageBridge.
WebRenderTextureHost is changed to permit to consume wrapped TextureHost on compositor thread. If the wrapped TextureHost is BufferTextureHost, it is possible to comsume the TextureHost on compositor and on RenderThread, since they are memory buffer or shared memory buffer. WebRTC code always create BufferTextureHost for video frame. Then it works.
Differential Revision: https://phabricator.services.mozilla.com/D34132
--HG--
extra : moz-landing-system : lando
We report the number of frames dropped by the compositor because they were too late through:
ImageComposite -> ImageHost -> CompositableTransactionParent -> ImageBridgeParent -> IPDL -> ImageBridgeChild -> ImageContainerListener -> ImageContainer -> VideoSink
Differential Revision: https://phabricator.services.mozilla.com/D2177
We can't rely on the FrameID continuity to determine if a frame has been dropped due to timing or not.
The reason being that the VideoSink will not send to the compositor frames it knows as being late already (causing a discontinuity in the frames IDs), and count them as being dropped.
If we were to look at discontinuity on the compositor we would account for those frames twice.
FramesID will also increase non-linearly if a frame isn't painted because it's not visible (either out of the visible tree or in a hidden tab).
What we can measure however, is when a frame should have been painted but didn't because it was too late by looking at the value returned by ImageComposite::ChooseImageIndex() or when a new set of images is being received by the ImageComposite.
Any images found in the earlier array but never returned must have been dropped due to timing.
Looking at the index continuity greatly simplify the logic as we no longer need to worry if a video is hidden or not, or be part of a layer that is itself hidden as neither SetImages will be called then, nor ChooseImage
For now, we only account for those frames dropped, and do not report them yet.
Differential Revision: https://phabricator.services.mozilla.com/D2176
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: 77D61xpSmIl
--HG--
extra : rebase_source : c6162fa3cf539a07177a19838324bf368faa162b
When WebRender creation is failed, WebRender is disabled in gecko. There is a case that WebRenderBridgeParents exist when WebRender is disabled. To handle this, gecko needs to rebuild all CompositorSessions.
There is also a problem related to gfxVars::UseWebRender on compositor thread. If e10s is enabled, but no-gpu process(default on linux and mac), gfxVars::UseWebRender change is soon notified by compositor thread tasks. If WebRender creation failure happens at 2nd WebRender creation, several WebRenderBridgeParents for 1st WebRender could exist. IPC messages from WebRenderLayerManager are normally async, then there is a chance that the WebRenderBridgeParents receive the messages after the gfxVars::UseWebRender change. Further the gfxVars::UseWebRender change in content process could be delayed than WebRenderBridgeParents, then content process does not have a way to stop sending PWebRenderBridge IPC until the change of gfxVars::UseWebRender is received. WebRenderBridgeParent related tasks handle the message, but some tasks are done based on gfxVars::UseWebRender. At this time, gfxVars::UseWebRender returned false on compositor thread, then it cause unexpected result for WebRenderBridgeParent and WebRender. To addres this inconsistent situation, WebRenderBridgeParent related tasks on compositor thread stop to use gfxVars::UseWebRender.
Add TextureSourceWebRenderOGL for WR GL composition.
Use BindTextureSource/UnbindTextureSource() to provide the TextureSource for WR external image rendering. Currently,only ImageHost supports these functions.
MozReview-Commit-ID: d5EvPUmlpq
- Generate and pass sequential frame indexes into the ovr_GetTrackingState call and the corresponding call to ovr_SubmitFrame
MozReview-Commit-ID: 5tJl5YJt7Eo
--HG--
extra : rebase_source : 5dbb35ea1451a9f378e28d81a8704b63b1b72b4d
Matrix4x4 remains a typedef for Matrix4x4Typed<UnknownUnits, UnknownUnits>.
No client code needed changing, except for forward-declarations of Matrix4x4
as a class (since it's now a typedef).
--HG--
extra : rebase_source : ecd9470b9defcc55cfb9e7dbd26e928a6219c3e5
extra : source : 0fc99b5490830953f37a4d8769e42dad2d10bc6e
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
sotaro
Sylvestre Ledru
Jean-Yves Avenard
Hiroyuki Ikezoe
Coroiu Cristina
David Anderson
Csoregi Natalia
Daniel Holbert
Matt Woodrow
Kartikaya Gupta
David Anderson
JerryShih
Miko Mynttinen
Kearwood (Kip) Gilbert
Jonathan Watt
Jeff Muizelaar
Wes Kocher
Nicolas Silva
kearwood
Johan Lorenzo
Botond Ballo
Nathan Froyd