ZoomToFocusedInput currently does not properly handle the
case where the input element is inside a nested scrollable subframe,
as it only asks APZ to pan/zoom the root content document, and
the root content document might not be zoomable or scrollable to
make the input element visible. To handle this case properly we need
to ask the main thread to scroll the element into view first.
Differential Revision: https://phabricator.services.mozilla.com/D20983
--HG--
extra : rebase_source : 21d2b66bb657b1165820d76fe86badb7838035da
extra : histedit_source : 996b4eebf9855445c11135f5f7a3789209b720f8%2C183ffc9ae30c1df4813204dd1bedf5b9f5608518
You tell me if this is right, I have no Windows build available to test :)
Depends on D25602
Differential Revision: https://phabricator.services.mozilla.com/D25603
--HG--
extra : moz-landing-system : lando
The only platforms that do not support GL_PACK_ROW_LENGTH are platforms with
GLES 2. So on those platforms, trying to read back into buffers whose stride is
not width * 4 will assert.
That's fine because we usually don't encounter buffers with such large strides
on GLES 2 platforms. The only platform that really needs to handle the large
strides is macOS, and it always supports GL_PACK_ROW_LENGTH.
On macOS, we often run into large strides on surfaces that we intend to upload
as textures at some point, because large stride alignments are required for
efficient upload performance on some drivers.
Bug 1540209 tracks fixing the general case.
Differential Revision: https://phabricator.services.mozilla.com/D25464
--HG--
extra : moz-landing-system : lando
In particular, it looks like this alignment is required by the Intel driver on
macOS if you want to avoid CPU copies.
It was already known that the efficiency gains from client storage only
materialize if you follow certain restrictions:
- The textures need to use the TEXTURE_RECTANGLE_ARB texture target.
- The textures' format, internalFormat and type need to be chosen from a small
list of supported configurations. Unsupported configurations will trigger
format conversions on the CPU.
- The GL_TEXTURE_STORAGE_HINT_APPLE may need to be set to shared or cached.
- glTextureRangeAPPLE may or may not make a difference.
It now appears that the stride alignment is another requirement:
When uploading textures which otherwise comply with the above requirements, the
Intel driver will still make copies using the CPU if the texture's stride is not
32-byte aligned. These CPU copies are reflected in a high CPU usage (as observed
in Activity Monitor) and they show up in profiles as time spent inside
_platform_memmove under glrUpdateTexture.
However, when uploading 32-byte stride aligned textures which comply with the
above requirements, this CPU usage goes away. There might still be hardware
copies behind the scenes, but they no longer take up CPU time.
Differential Revision: https://phabricator.services.mozilla.com/D25316
--HG--
extra : moz-landing-system : lando
UA style sheets only ever specify a single generic font family in font-family
properties, so we pre-create a unique, static SharedFontList for each generic
and change the representation of FontFamilyList to be able to refer to them
by their generic ID. This avoids having to share refcounted SharedFontList
objects across processes.
Depends on D17182
Differential Revision: https://phabricator.services.mozilla.com/D17183
--HG--
extra : moz-landing-system : lando
This will allow upcoming shared font-list to use the same helpers as the existing code.
Differential Revision: https://phabricator.services.mozilla.com/D22926
--HG--
extra : moz-landing-system : lando
This allows us to reduce #include usage of the massive gfxFont.h header,
and keeps this specialized kind of TextRange struct local to where it's used.
Differential Revision: https://phabricator.services.mozilla.com/D22904
--HG--
extra : moz-landing-system : lando
This autofill popover was being displayed in the incorrect place because the display rect we were providing to the `AutofillManager` was the rect for the `GeckoView` and not the rect for the HTML element that the autofill popover was relating to.
1. Add view dimensions to info passed to autofill in `GeckoViewAutoFill`.
2. Use those view dimensions to calculate the correct location on the screen using `pageToScreenMatrix` in `GeckoSession`.
The resulting locations were incorrect, as the values used by `pageToScreenMatrix` were out of date. The `GeckoSession` was only notified about updated metrics during first composite, which meant that when the metrics changed during zoom and scroll on soft keyboard presentation, `GeckoSession` was unaware of it.
3. Update `GeckoSession` with new screen metrics when they change and not only during first composite.
Despite this change ensuring that `GeckoSession` always had the correct values for the viewport size and location, the request to provide the autofill location was made before the zoom and scroll was complete, meaning that even then out of date values were used during the calculation. The intial solution was to fire an event once zoom was complete, but despite this event being fired after the new screen size had been calculcated in `AsyncCompositionManager`, `GeckoSession` did not receive the values until after the event had been processed (the calls were out by 0.024ms).
5. Call new method `onScreenMetricsUpdated` inside `SessionTextInput` after screen metrics have been updated. Call `AutofillManager#notifyViewEntered` from this function.
This was not my preferred solution to this, but timing issues meant I could not find/think of an alternative way of delaying the calculation of the autofill popover location until after `GeckoSession` had been updated.
This patch currently fixes things on GV apps. Occasionally, on Fennec, the autofill view is out of alignment slightly. This needs further work.
Differential Revision: https://phabricator.services.mozilla.com/D25406
--HG--
extra : moz-landing-system : lando
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
Bug 1416015 and Bug 1470348 added function calls for CompositorOGL. Similar things needs to be done for RenderCompositorEGL.
Differential Revision: https://phabricator.services.mozilla.com/D25199
--HG--
extra : moz-landing-system : lando
A spatial id of 0 refers to the root reference frame on the WR side, but
we shouldn't be using that on the Gecko side at all. Due to the
early-exit codepath in ClipManager we were actually sending some display
items with this spatial id over to WebRender. Although this doesn't
appear to cause any user-visible problems it seems wrong and can confuse
debugging other issues.
Differential Revision: https://phabricator.services.mozilla.com/D25296
--HG--
extra : moz-landing-system : lando
This autofill popover was being displayed in the incorrect place because the display rect we were providing to the `AutofillManager` was the rect for the `GeckoView` and not the rect for the HTML element that the autofill popover was relating to.
1. Add view dimensions to info passed to autofill in `GeckoViewAutoFill`.
2. Use those view dimensions to calculate the correct location on the screen using `pageToScreenMatrix` in `GeckoSession`.
The resulting locations were incorrect, as the values used by `pageToScreenMatrix` were out of date. The `GeckoSession` was only notified about updated metrics during first composite, which meant that when the metrics changed during zoom and scroll on soft keyboard presentation, `GeckoSession` was unaware of it.
3. Update `GeckoSession` with new screen metrics when they change and not only during first composite.
Despite this change ensuring that `GeckoSession` always had the correct values for the viewport size and location, the request to provide the autofill location was made before the zoom and scroll was complete, meaning that even then out of date values were used during the calculation. The intial solution was to fire an event once zoom was complete, but despite this event being fired after the new screen size had been calculcated in `AsyncCompositionManager`, `GeckoSession` did not receive the values until after the event had been processed (the calls were out by 0.024ms).
5. Call new method `onScreenMetricsUpdated` inside `SessionTextInput` after screen metrics have been updated. Call `AutofillManager#notifyViewEntered` from this function.
This was not my preferred solution to this, but timing issues meant I could not find/think of an alternative way of delaying the calculation of the autofill popover location until after `GeckoSession` had been updated.
This patch currently fixes things on GV apps. Occasionally, on Fennec, the autofill view is out of alignment slightly. This needs further work.
Differential Revision: https://phabricator.services.mozilla.com/D24397
--HG--
extra : moz-landing-system : lando
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
In particular, it looks like this alignment is required by the Intel driver on
macOS if you want to avoid CPU copies.
It was already known that the efficiency gains from ClientStorage only
materialize if you follow certain restrictions:
- The textures need to use the TEXTURE_RECTANGLE_ARB texture target.
- The textures' format, internalFormat and type need to be chosen from a small
list of supported configurations. Unsupported configurations will trigger
format conversions on the CPU.
- The GL_TEXTURE_STORAGE_HINT_APPLE may need to be set to shared or cached.
- glTextureRangeAPPLE may or may not make a difference.
It now appears that the stride alignment is another requirement:
When uploading textures which otherwise comply with the above requirements, the
Intel driver will still make copies using the CPU if the texture's stride is not
32-byte aligned. These CPU copies are reflected in a high CPU usage (as observed
in Activity Monitor) and they show up in profiles as time spent inside
_platform_memmove under glrUpdateTexture.
However, when uploading 32-byte stride aligned textures which comply with the
above requirements, this CPU usage goes away. There might still be hardware
copies behind the scenes, but they no longer take up CPU time.
Differential Revision: https://phabricator.services.mozilla.com/D25316
--HG--
extra : moz-landing-system : lando
The main change here is removing some rounding so that we can do more
accurate hit-testing in APZ. Instead of rounding both the rect and the
point, we just store both as unrounded values. mRenderRootRects is also
changed to be of a Screen type as that better reflects what it's being
used for, and there is a legitimate justification for converting it from
LayoutDevice.
Depends on D25239
Differential Revision: https://phabricator.services.mozilla.com/D25240
--HG--
extra : moz-landing-system : lando
We use a strongly typed LayoutDevice rect because that's the correct
type for this rect. And we defer the rounding to the parent side for
more precise hit-testing (see next patch).
Depends on D25238
Differential Revision: https://phabricator.services.mozilla.com/D25239
--HG--
extra : moz-landing-system : lando
The receiver of this parameter treats it as a layout size, so it doesn't
make sense for the argument to be a LayerSize partway through the call
chain. Also the callers originally get this from a LayoutDevice rect;
so there's even less reason for this to be turned into a LayerSize. The
next patch will propagate this cleanup more.
Differential Revision: https://phabricator.services.mozilla.com/D25238
--HG--
extra : moz-landing-system : lando
Cosmin Sabou
Makoto Kato
Sylvestre Ledru
Emilio Cobos Álvarez
Lee Salzman
Narcis Beleuzu
Markus Stange
Cameron McCormack
Alex Gaynor
Noemi Erli
Jeff Gilbert
Botond Ballo
Jonathan Kew
Kartikaya Gupta
Emily Toop
Masayuki Nakano
sotaro
Dorel Luca
Gurzau Raul
Matt Woodrow
Brad Werth
Barret Rennie