The root displayport has some assumptions built into it about being positioned at
the origin and sized to the composition bounds that seem like they only apply to
the cross process root content document. This commit changes us to avoid taking
this code path for OOP-iframes.
Differential Revision: https://phabricator.services.mozilla.com/D34527
--HG--
extra : rebase_source : 026bb84b7ad086f508228620d19d9f459f28bf1d
This makes the assertion failure from bug 1553045 reproduce with WR enabled.
Differential Revision: https://phabricator.services.mozilla.com/D34625
--HG--
extra : moz-landing-system : lando
There are a number of failures, for which I've filed separate bugs.
And then a lot of fuzziness. I manually inspected the reftest analyzer
results on try pushes to distinguish failures vs fuzziness.
Depends on D34537
Differential Revision: https://phabricator.services.mozilla.com/D34538
--HG--
extra : moz-landing-system : lando
The tile cache is 352 bytes large and in the majority of cases picture primitives don't have one, so this saves a few KB of ram in typical pages reduces the likely hood of hitting OOM crashes while growing the primitives vector.
Differential Revision: https://phabricator.services.mozilla.com/D34346
--HG--
extra : moz-landing-system : lando
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
The profiler will require non-fuzzed timers for accuracy. Making the switch early will avoid surprises when FuzzyFox is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D31010
--HG--
extra : moz-landing-system : lando
If the GPU process becomes disabled due to crashes, then we should not
allow Linux to fallback from WebRender to OpenGL compositing in the
parent process. It should instead fallback to software just like
Windows. This is important because we don't support the OpenGL
compositor configuration.
Differential Revision: https://phabricator.services.mozilla.com/D34360
This preserves the APZ invariant that if there is an async zoom container,
then the RCD-RSF scroll metadata is on the same layer or descendant layers.
Differential Revision: https://phabricator.services.mozilla.com/D34255
--HG--
extra : moz-landing-system : lando
This mostly already works, e.g. AsyncCompositionManager will apply both parts
of the transform independently, just a check in APZCTreeManager::
ComputeTransformForNode() needed to be adjusted.
Differential Revision: https://phabricator.services.mozilla.com/D34253
--HG--
extra : moz-landing-system : lando
The presence or absence of the DEVICE_SERIAL environment variable
is sufficient to control this.
Differential Revision: https://phabricator.services.mozilla.com/D33407
--HG--
extra : moz-landing-system : lando
This is in preparation for having the same script be used for emulator
and device runs. No functional change in this patch; it just renames
the file and class.
Differential Revision: https://phabricator.services.mozilla.com/D33406
--HG--
rename : testing/mozharness/scripts/android_emulator_wrench.py => testing/mozharness/scripts/android_wrench.py
extra : moz-landing-system : lando
To run task_for_pid() on child processes, we need the child task port for
security reasons. This port can be obtained via a Mach IPC exchange.
This is what GeckoChildProcessHost::GetChildTask() provides, so we use it
in cocoa's version of GetProcInfo()
Differential Revision: https://phabricator.services.mozilla.com/D25927
--HG--
extra : moz-landing-system : lando
Even if we have no clips applied it's valuable to give back the surface size.
Differential Revision: https://phabricator.services.mozilla.com/D33535
--HG--
extra : moz-landing-system : lando
I needed this change to make things work with my CreateClippedDrawTarget. It
seems reasonable but I can't justify it rigorously.
Differential Revision: https://phabricator.services.mozilla.com/D33527
--HG--
extra : moz-landing-system : lando
Force perspective interpolation of UV coordinates in clip shaders.
In addition to fixing the interpolation curve, also adds checks for the homogeneous coordinates to be outside of the meaningful hemisphere, forcing the clip shaders to output zeroes in those areas.
Differential Revision: https://phabricator.services.mozilla.com/D34017
--HG--
extra : moz-landing-system : lando
This is similar to bug 1551582, but concerns a main-thread change to the
composition bounds rather than the scrollable rect; either can result in
the scroll range shrinking and therefore a need to re-clamp the scroll offset.
Differential Revision: https://phabricator.services.mozilla.com/D34211
--HG--
extra : moz-landing-system : lando
