The tracking is done using nsAtom origins, similarly to how updates to the
scroll offset are tracked.
Currently, APZ still uses some heuristics to deduce that the main thread
originated a resolution change in some cases, but the intention is to try
to remove those and rely only on this mechanism in the future.
Differential Revision: https://phabricator.services.mozilla.com/D13741
--HG--
extra : moz-landing-system : lando
These macros tend to be handled quite poorly since the clang-format
tokenizer cannot figure out how to handle them.
Differential Revision: https://phabricator.services.mozilla.com/D13179
--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
This commit adds a scroll origin, nsGkAtoms::relative, which can be used to
mark main thread scrolling that can be combined with a concurrent APZ scroll.
The behavior of this is controlled by a pref, apz.relative-update. This pref
is initially activated and is intended as an aid to narrowing down causes
of regressions for users in bug reports.
Relative scroll updates work by tracking the last sent or accepted APZ
scroll offset. This is sent along with every FrameMetrics. Additionally,
a flag is added to FrameMetrics, mIsRelative, indicating whether the
scroll offset can be combined with a potential APZ scroll. When this
flag is set, AsyncPanZoomController will apply the delta between the sent
base scroll offset, and sent new scroll offset.
This flag is controlled by the last scroll origin on nsGfxScrollFrame. The
new origin, `relative`, is marked as being able to clobber APZ updates,
but can only be set if all scrolls since the last repaint request or
layers transaction have been relative.
Differential Revision: https://phabricator.services.mozilla.com/D8234
--HG--
extra : rebase_source : 51351a84c9cda228a0975e22eda3fd3bd8d261c4
extra : histedit_source : 4b564c19b16fe2bd26adc671b62b7cb6106e8163
FrameMetrics is currently used in about three ways.
1. Main thread to APZ transactions
2. Storing information in AsyncPanZoomController
3. APZ to main thread repaint requests
There's overlap in the use of fields in all these use cases, but it's not perfect. In a
following commit, I'd like to change the information used for (1) to support relative
scroll offset updates. This information isn't needed for (2) or (3), so it would be
good to refactor FrameMetrics out into these use cases.
This commit refactors out (3) as it is fairly easy to do. I'd like to refactor (2) out
as well, but that is trickier. I'd like to leave that for a future followup.
Differential Revision: https://phabricator.services.mozilla.com/D7127
--HG--
extra : rebase_source : f0be2be24fce7d0f0ed25f6f3bfab5f7f2864f23
extra : source : fc9898a9ab28cee292e201ddaf757ee267179433
extra : histedit_source : 35415d3dc2c0ae0f269994c385cceff75f150020
There are 3 main components to this change:
a) Store the origin of the layout viewport in APZ (until now we only stored
it's size). This required updating the offset stored in mViewport, which
was previously (0, 0).
b) Adjust the layout viewport in APZ each time the visual viewport exceeds
the bounds of the layout viewport.
c) Update the main thread to store the layout viewport offset for the
RCD-RSF (currently it uses the layout viewport offset for overflow:hidden
pages, and the visual viewport offset otherwise).
MozReview-Commit-ID: 7AD8wvthh2m
--HG--
extra : rebase_source : df8704146740f4b2522c80b20b603617993b6c83
- Fix the implementation to return a numerically correct result
- Change call sites that should have instead been using
CalculateCompositedSizeInCssPixels(), to do so
- Rename and document to emphasize that the returned rect is in the
CSS pixels of the content surrounding the scroll frame
MozReview-Commit-ID: GCPbA1k88rz
--HG--
extra : rebase_source : f5b937936fb84b3ae414d6cf0250add4078a9d53
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
The majority of this patch is just plumbing. The interesting parts are
in WebRenderLayerManager and APZUpdater/WebRenderScrollData. Unlike
ClientLayerManager, which updates the FrameMetrics on the client side
and sends the modified version over to the compositor, this WR version
just sends the update info over to the compositor, which then applies
the update to the metrics saved in APZUpdater before triggering the
hit-testing tree rebuild.
MozReview-Commit-ID: 4latUMa8RFw
--HG--
extra : rebase_source : d0aeaf5a9c8107bbcaf8b0da6d68a0f47f455be5
This is mostly just moving the existing hash function and introducing
additional helpers to create maps with presshell-ignoring guid keys. We
can use this in one place trivially so I did that as well.
MozReview-Commit-ID: G8nMS1PECT4
--HG--
extra : rebase_source : 4f34da9db77f7ec4b7e5ebaeccd532c8f8c92283
With this commit, all the auto-dir scrolling functionalities are completed in
APZ.
MozReview-Commit-ID: L7qa3xOD8t9
--HG--
extra : rebase_source : bad2770219a0e6219f91899ab6c78e68f37195ac
This commit implements the auto-dir scrolling functionality in APZ, based on
part 1 to part 3. However, the functionality of mousewheel.autodir.honourroot
will be implemented in a future.
MozReview-Commit-ID: 9xai99x71gh
--HG--
extra : rebase_source : 118d188f730e3fb91d147b076a053cb04e622e55
The new struct is in LayersTypes.h, all the rest of the changes are just
replacing existing uint64_t instances with the new LayersId struct.
Note that there is one functional change, in
CompositorBridgeParent::DeallocPWebRenderBridgeParent, where we now
correctly convert the PipelineId to a LayersId before using it to index
into sIndirectLayerTrees, whereas before we were incorrectly just using
the mHandle part of the PipelineId.
MozReview-Commit-ID: GFHZSZiwMrP
--HG--
extra : rebase_source : d2b274f63aaee2ee9bba030297e0a37a19af0d6c
(This is a helper patch -- I'm splitting this into its own patch since it's
changing files in other directories, and also so that the main patches here
can be a bit more direct.)
Without this change, the other patches in this series would cause compile
failures in the headers that I'm fixing up here (because the other patches will
be removing #includes from some headers that these files were inadvertently
depending on).
As of this patch, ComputedTimingFunction.h will now be including:
- nsDebug.h to provide NS_ASSERTION
- nsStringFwd.h to provide a forward-declaration for "nsAString&"
- Assertions.h to provide MOZ_ASSERT
- Maybe.h to provide Maybe<ComputedTimingFunction>
(I think it's been leaning on nsTimingFunction.h's include of nsString.h to
indirectly provide these.)
FrameMetrics.h will now be including:
- PLDHashTable.h to provide PLDHashNumber
(I think it's been leaning on nsStyleCoord.h/nsStyleConsts.h to indirectly
provide this.)
MozReview-Commit-ID: AoFoEe9GisK
--HG--
extra : rebase_source : 63c69343acaf42511ebdeb0238f4385a0c6345a5
As for now, the scrollable direction with a mouse wheel for a single-line text
control is hard-coded; that is, only horizontal wheel scrolls are able to take
effect while vertical ones aren't. However, this isn't the desired case for
vertical writing mode, where the opposite case definitely suits better.
This commit refines the hard-coded scrollable direction for a single-line text
control to be writing-mode-adaptive.
MozReview-Commit-ID: 4Zkoe2ExPCZ
--HG--
extra : rebase_source : 113b2ea80b6bbbcd2d8379b438de97eedd616551
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
Also tweaks the documentation in FrameMetrics.h to be more detailed and
less misleading.
MozReview-Commit-ID: 183V2Q9kY6C
--HG--
extra : rebase_source : 9fb08cf9c2a9df68637fb26014f637b0cb40b188
MozReview-Commit-ID: yHXUFw2fx6
***
Bug 1367062 - Change std::map to std::unordered_map in APZCTreeManager
changed gfx/layers/FrameMetrics.h by adding a ScrollableLayerGuidHash class that will be used as the hashing function for std::unordered_maps which use ScrollableLayerGuid as keys.
changed gfx/layers/apz/src/APZCTreeManager.cpp by changing mApzcMap to a std::unordered_map.
changed gfx/layers/apz/src/APZCTreeManager.h by changing mZoomConstraints to a std::unordered_map.
MozReview-Commit-ID: JmoQzh1MvKK
--HG--
extra : rebase_source : cb7bd9419085f83873c9fd019c4a379fae0ee278
Previously we weren't sending scroll position updates with origin nsGkAtoms::restore
over to the APZ at all, on the assumption that they should never clobber an APZ
scroll offset. However, there are scenarios where that is not true.
In particular, during a frame reconstruction, a layers update may be sent to the
compositor between the time a scrollframe has RestoreState() called on it, and
the time the scrollframe has ScrollToRestoredPosition() called on it. The layers
update that happens during this interval (correctly) sends a scroll position of
(0,0), and forces the APZ to scroll to that position. This is necessary to
prevent APZ from remaining at an invalid scroll offset while the frame is still
being rebuilt.
However, once ScrollToRestoredPosition() is called and the old scroll offset is
restored, that restored scroll position needs to get sent to the APZ in order to
have it properly restore to the original scroll position. In order to do this,
the main thread must flag the metrics with a scroll offset update. Since the user
may have scrolled concurrently in the compositor from the (0,0) position, we also
need to check for that case in the APZ code and avoid restoring the scroll
position. This is equivalent to the corresponding main-thread code in
ScrollToRestoredPosition().
MozReview-Commit-ID: LxRapVSrsJ3
Avoiding these re-scrolls prevents APZ repaint requests from clobbering the
main-thread scroll position (which may have changed in the meantime) in some
cases. See https://bugzilla.mozilla.org/show_bug.cgi?id=1286179#c8 for an example
of a scenario where this re-scroll is problematic.
MozReview-Commit-ID: 7he2A2sygji
--HG--
extra : rebase_source : 9fea76c2497eb131fba0ff4a82018309be6e1ef0
The division-by-zero was introducing NaNs into the displayport calculations,
resulting in bad displayports.
MozReview-Commit-ID: 5dbqIEOFADS
--HG--
extra : source : 569276f2edd39600de534183e12b7f8762b917c8
