This helper will be reused for translating layers fixed to the RCD-RSF
with containerless scrolling.
Differential Revision: https://phabricator.services.mozilla.com/D17723
--HG--
extra : moz-landing-system : lando
This reflects the fact that it's no longer optional (the code path that
wouldn't pass one was removed with JPZC).
Differential Revision: https://phabricator.services.mozilla.com/D17722
--HG--
extra : moz-landing-system : lando
This commit adds categories to all markers. This way the profiler's
marker categories and frame label categories agree. There are a few
duplicate category properties on some of the marker payloads, but
this could be cleaned up in a follow-up if needed.
Differential Revision: https://phabricator.services.mozilla.com/D16864
--HG--
extra : moz-landing-system : lando
When selected text in `geckoview_example`, the text selection toolbar was always positioned in the top left corner of the screen, regardless of where in the page the text was selected.
The cause of the bug was that UpdateRootFrameMetrics was being called only if the app utilised the `AndroidDynamicToolbar`. This caused the `mViewportZoom` value inside `GeckoSession` to always be 0. When using the `clientToFrameMatrix` function to place the text selection toolbar on screen, the generated matrix was incorrect as the zoom value was 0, causing the resulting frame to be offset by the zoom value.
By ensuring that `UpdateRootFrameMetrics` is called inside `AsyncCompositionManager`even when there is no `AndroidDynamicToolbarAnimator` this zoom value is correctly set and the resulting frame for the text selection toolbar is correctly placed.
Differential Revision: https://phabricator.services.mozilla.com/D15941
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13193
--HG--
extra : moz-landing-system : lando
Changes for nsIDOMWindowUtils.getOMTAValue is in the next commit with come test
cases.
Differential Revision: https://phabricator.services.mozilla.com/D13001
--HG--
extra : moz-landing-system : lando
Changes for nsIDOMWindowUtils.getOMTAValue is in the next commit with come test
cases.
Differential Revision: https://phabricator.services.mozilla.com/D13001
--HG--
extra : moz-landing-system : lando
(Unless there were other profiler actions, as I'm not sure yet whether it would
be safe to skip them when the profiler is paused; another bug should
investigate that.)
Differential Revision: https://phabricator.services.mozilla.com/D11308
--HG--
extra : moz-landing-system : lando
This commit attempts to lower the pain of modifying FrameMetrics.h.
It looks like most includes really only want ViewID or
ScrollableLayerGuid, so this commit factors them out into a separate
header. In the process FrameMetrics::ViewID is changed to
ScrollableLayerGuid::ViewID, which personally seems like a better
place for it now that we have RepaintRequest. Unfortunately that
requires a lot of places to be updated.
After this commit there are still a couple of major places that
FrameMetrics is included.
* nsDisplayList.h
* nsIScrollableFrame.h
* Layers.h
Those are going to be more tricky or impossible to fix so they're
not in this commit.
Differential Revision: https://phabricator.services.mozilla.com/D10722
--HG--
rename : gfx/layers/FrameMetrics.h => gfx/layers/ScrollableLayerGuid.h
rename : gfx/layers/FrameMetrics.h => gfx/layers/ZoomConstraints.h
extra : rebase_source : 29ac79f91460a181bf7437af5c371207e22858e2
extra : source : c2e70e531075493fc6e374dcec862827f0bc6e77
The bulk of this is adjusting the code that tries to use the toolbar to
have appropriate null checks instead of asserting it will exist. The
creation of the animator instance is now guarded by a IsFennec
condition.
Depends on D8658
Differential Revision: https://phabricator.services.mozilla.com/D8659
--HG--
extra : moz-landing-system : lando
This extracts code that is conceptually unrelated to the dynamic toolbar
from the dynamic toolbar codebase. It is a stepping stone to being able
to not instantiate the AndroidDynamicToolbarAnimator at all for
non-Fennec android products.
Differential Revision: https://phabricator.services.mozilla.com/D8657
--HG--
extra : moz-landing-system : lando
I wish I understood a little better what precisely is going on
here. What seems to be the problem is calling glDeleteTextures
too early, but I can't pin down exactly when "too early" is.
In any case I can no longer reproduce the issue with this patch
applied, and I cannot observe any performance degradation, and
it's not a remarkably risky patch, so I'm opting to cut the
investigation short. Any insights would be appreciated though.
Differential Revision: https://phabricator.services.mozilla.com/D6064
--HG--
extra : moz-landing-system : lando
I wish I understood a little better what precisely is going on
here. What seems to be the problem is calling glDeleteTextures
too early, but I can't pin down exactly when "too early" is.
In any case I can no longer reproduce the issue with this patch
applied, and I cannot observe any performance degradation, and
it's not a remarkably risky patch, so I'm opting to cut the
investigation short. Any insights would be appreciated though.
Differential Revision: https://phabricator.services.mozilla.com/D6064
--HG--
extra : moz-landing-system : lando
This patch removes the 'ScreenOrientationInternal' type from
dom/base/ScreenOrientation.h and moves it into the
HalScreenConfiguration.h header, renaming it simply to 'ScreenOrientation'
in the process. This has several knock-off effects:
- It allows files that needed ScreenOrientationInternal to include a much
smaller header than before
- It greatly reduces the number of headers pulled in when including Hal.h
- It clarifies the role of the type. The 'Internal' part in the name had
nothing to do with it being part of the implementation. The type was public
and called that way only to avoid clashing with the 'ScreenOrientation'
class. Since we moved it into a different namespace it can be renamed
safely.
- It allows a file that was manually re-declaring 'ScreenConfigurationInternal'
type to use the original one
- Finally this fixes a few files which were missing headers they actually
required but that would still build because unified compilation put them into
units that already had those headers thanks to ScreenConfiguration.h
Differential Revision: https://phabricator.services.mozilla.com/D4458
--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
We will use the characteristic of which TimedImage is returned to keep track on how many frames were dropped because they were too old. As such, we must make sure the retrieval of the current image is serialised.
This allows to reduce duplicated code between WebRenderImageHost and ImageHost classes.
Additionally, make RenderInfo::img member const as really, we never want to modify that one.
A future change will enforce that RenderInfo.img never survives longer than the ChooseImage()'s caller to clarify the lifetime of the TimedImage.
Differential Revision: https://phabricator.services.mozilla.com/D2175
This patch was generated using a simple sed script:
sed -i 's/ToUnknownRegion().GetBounds()/GetBounds().ToUnknownRect()/g' gfx/**/*.cpp gfx/**/*.h
Differential Revision: https://phabricator.services.mozilla.com/D3875
--HG--
extra : rebase_source : 4e9e7c9f2fb4ca60122712dd06632147cdec7195
This results in fixed position elements being attached to the layout viewport
when being async-scrolled by APZ (when the layout viewport is larger than the
visual viewport).
MozReview-Commit-ID: 2YYIDnTWgVn
--HG--
extra : rebase_source : 58b77b2e9c8ed35bdc2d24dd8ca9494e8d23a391
Includes a new RAII class: AutoApplyAsyncTestAttributes, which, for the
duration of its lifetime, applies mTestAsyncScrollOffset and mTestAsyncZoom to
the APZC's FrameMetrics. We need this to ensure that the
AsyncPanZoomController::GetCurrentAsync* methods consider test scroll and zoom
attributes when doing their respective computations.
MozReview-Commit-ID: 9owJcdIegNH
--HG--
extra : rebase_source : 35273faf10b8db13e3b5485278262f93d4adc579
