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
Simplify error handling in GLContext.
Modernize context loss handling in GLContext.
Remove various unused parts.
Fix WebGLContext's context loss/restoration.
MozReview-Commit-ID: Lu2hi5HnP8x
Differential Revision: https://phabricator.services.mozilla.com/D12496
--HG--
extra : moz-landing-system : lando
Normandy's Preference Rollout code sets default values on prefs, not user
values (see uses of PrefUtils.setPref() in PreferenceRolloutAction.jsm).
Default prefs are not persistent; unlike user prefs, changes to default pref
values are not stored on disk. Changes to default values are only made on the
in-memory copy of the pref's value, and thus don't survive a browser restart.
Normandy changes the rolled out prefs early on in the startup of the browser,
but not before gfxPlatform::Init() runs. So that means gfx can't use Normandy
pref rollout to gradually rollout WebRender to release, as
gfxPlatform::InitWebRenderConfig() won't see the rolled out version of the
pref in time to turn on WebRender.
So to work around this, add a profile-before-change shutdown observer that
saves the default value of the gfx.webrender.all.qualified pref to a new user
pref, gfx.webrender.all.qualified.default. We check that on startup and
emulate the behavior that the pref system would have if that pref default
value had already been set by Normandy.
Differential Revision: https://phabricator.services.mozilla.com/D10527
--HG--
extra : moz-landing-system : lando
Normandy's Preference Rollout code sets default values on prefs, not user
values (see uses of PrefUtils.setPref() in PreferenceRolloutAction.jsm).
Default prefs are not persistent; unlike user prefs, changes to default pref
values are not stored on disk. Changes to default values are only made on the
in-memory copy of the pref's value, and thus don't survive a browser restart.
Normandy changes the rolled out prefs early on in the startup of the browser,
but not before gfxPlatform::Init() runs. So that means gfx can't use Normandy
pref rollout to gradually rollout WebRender to release, as
gfxPlatform::InitWebRenderConfig() won't see the rolled out version of the
pref in time to turn on WebRender.
So to work around this, add a profile-before-change shutdown observer that
saves the default value of the gfx.webrender.all.qualified pref to a new user
pref, gfx.webrender.all.qualified.default. We check that on startup and
emulate the behavior that the pref system would have if that pref default
value had already been set by Normandy.
Differential Revision: https://phabricator.services.mozilla.com/D10527
--HG--
extra : moz-landing-system : lando
Normandy's Preference Rollout code sets default values on prefs, not user
values (see uses of PrefUtils.setPref() in PreferenceRolloutAction.jsm).
Default prefs are not persistent; unlike user prefs, changes to default pref
values are not stored on disk. Changes to default values are only made on the
in-memory copy of the pref's value, and thus don't survive a browser restart.
Normandy changes the rolled out prefs early on in the startup of the browser,
but not before gfxPlatform::Init() runs. So that means gfx can't use Normandy
pref rollout to gradually rollout WebRender to release, as
gfxPlatform::InitWebRenderConfig() won't see the rolled out version of the
pref in time to turn on WebRender.
So to work around this, add a profile-before-change shutdown observer that
saves the default value of the gfx.webrender.all.qualified pref to a new user
pref, gfx.webrender.all.qualified.default. We check that on startup and
emulate the behavior that the pref system would have if that pref default
value had already been set by Normandy.
Differential Revision: https://phabricator.services.mozilla.com/D10527
--HG--
extra : moz-landing-system : lando
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
This is not really the best fix (a better one would be to ensure that the
displayport is set on the root element of the gfx sanity window), but should
do as a stopgap solution.
Differential Revision: https://phabricator.services.mozilla.com/D9667
--HG--
extra : moz-landing-system : lando
This is what we have been working towards in all of the previous parts
in the series. This subclasses AnimationFrameDiscardingQueue to save the
discarded frames for recycling by the decoder, if the frame is marked as
supporting recycling.
Differential Revision: https://phabricator.services.mozilla.com/D7516
This was an experiment before we had e10s. It's no longer needed.
Depends on D7922
Differential Revision: https://phabricator.services.mozilla.com/D7924
--HG--
extra : moz-landing-system : lando
This changes the containerful scrolling pref to be an override pref
such that it is:
- always false on desktop (i.e. always use containerless there)
- always true in Fennec (i.e. never use containerless there)
- true in GeckoView if WebRender is disabled (i.e. only use
containerless with WebRender).
The first two cases are the same as before; the last case is new.
Because we don't create layers with WR, the containerless vs
containerful distinction doesn't make much sense there, and we need to
implement a bunch of zooming glue in either case. So it makes sense to
go with the "way of the future" and keep it containerless.
Differential Revision: https://phabricator.services.mozilla.com/D8733
--HG--
extra : moz-landing-system : lando
It just doesn't work.
We add the preference media.wmf.force.allow-p010-format to force enable it.
Depends on D8136
Differential Revision: https://phabricator.services.mozilla.com/D8310
--HG--
extra : moz-landing-system : lando
All of its callers are in painting code, so changes will take effect on the
next paint, so there is no need for it to be a Once pref.
Making it Live allows us to selectively enable it in specific mochitests.
Differential Revision: https://phabricator.services.mozilla.com/D7340
--HG--
extra : rebase_source : 772e3c49f5e945d37126979b1c1edab691788e63
extra : histedit_source : 34eccab0c8ab664f15787626bff72f261718ea9c
By delegating responsibility for shared surfaces reporting to imagelib,
we can cross reference the GPU shared surfaces cache with the local
surface cache in a content process (or the main process). This will
allow us to identify entries that are in the GPU cache but not in the
content/main process cache, and aid in debugging memory leaks. This
functionality is pref'd off by default behind image.mem.debug-reporting.
Additionally, we want to report every entry that was mapped into the
compositor process, in the compositor process memory report. This will
give us a sense of how much of our resident memory is consumed by mapped
images in absence of the more detailed cross referencing above.
By delegating responsibility for shared surfaces reporting to imagelib,
we can cross reference the GPU shared surfaces cache with the local
surface cache in a content process (or the main process). This will
allow us to identify entries that are in the GPU cache but not in the
content/main process cache, and aid in debugging memory leaks. This
functionality is pref'd off by default behind image.mem.debug-reporting.
Additionally, we want to report every entry that was mapped into the
compositor process, in the compositor process memory report. This will
give us a sense of how much of our resident memory is consumed by mapped
images in absence of the more detailed cross referencing above.
There is one main difference between raster images and vector images
with respect to factor of 2 scaling. Vector images may be scaled
infinitely and so we need to extend factor of 2 scaling to permit
growing instead of just shrinking. Also, we don't want to scale
infinitely, so we should configure a maximum size limit. This size limit
will apply even outside of factor of 2 scaling, and so the caller
(VectorImage) will need to be careful to take this into account.
There is one main difference between raster images and vector images
with respect to factor of 2 scaling. Vector images may be scaled
infinitely and so we need to extend factor of 2 scaling to permit
growing instead of just shrinking. Also, we don't want to scale
infinitely, so we should configure a maximum size limit. This size limit
will apply even outside of factor of 2 scaling, and so the caller
(VectorImage) will need to be careful to take this into account.