Mechanical change from Matcher::match(...) to Matcher::operator()(...).
This will now permit the use of generic lambdas, and facilitate the
implementation of multi-lambda match.
Differential Revision: https://phabricator.services.mozilla.com/D24889
--HG--
extra : moz-landing-system : lando
On android, we want to use only RenderCompositorEGL for using sharedGL. Further RenderCompositorOGL does not work well with android SurfaceTexture.
Differential Revision: https://phabricator.services.mozilla.com/D25201
--HG--
extra : moz-landing-system : lando
As discussed on IRC, fixed is only used for prefs right now, and:
* We already copy the fixed size to the monospace font.
* We already serialize the fixed family as "monospace" in the style system.
So it already works somewhat inconsistently. Making it an alias makes it
work consistently.
Differential Revision: https://phabricator.services.mozilla.com/D24288
--HG--
extra : moz-landing-system : lando
To be more similar between Rust and C++. This introduces GenericFontFamily and
exposes that plus FontFamilyNameSyntax to C++, using that where appropriate
instead of plain uint8_t as we were doing.
As a follow-up, as discussed on IRC with Jonathan, we can remove the -moz-fixed
family, and turn it just into an alias of Monospace.
The only non-trivial change is the MatchType changes, but they're ok I think.
The code already assumed at most one CSS generic, and the struct still takes 8
bits. I've verified that the relevant tests are passing (though try is closed).
Differential Revision: https://phabricator.services.mozilla.com/D24272
--HG--
extra : moz-landing-system : lando
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
Jeff Gilbert
Matt Woodrow
Gerald Squelart
Daosheng Mu
sotaro
arthur.iakab
Emilio Cobos Álvarez
Cosmin Sabou
Makoto Kato
Sylvestre Ledru
Lee Salzman
Narcis Beleuzu
Markus Stange
Cameron McCormack
Alex Gaynor
Noemi Erli
Botond Ballo
Jonathan Kew
Kartikaya Gupta
Emily Toop
Masayuki Nakano
Dorel Luca
Gurzau Raul