Listing the preferences in either all.js or StaticPrefList.h would also make them appear in about:config which is something we don't want.
Additionally, rename some pref constants to improve code clarity as we can no longer rely on using the StaticPrefs accessor.
Differential Revision: https://phabricator.services.mozilla.com/D32416
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
StaticPrefs doesn't support nsCString type and the changes required to support this would be rather big. Seeing that there was only a single gfxPrefs using this, and this is a "Once" pref ; we move it to gfxVars instead.
Differential Revision: https://phabricator.services.mozilla.com/D31462
--HG--
extra : moz-landing-system : lando
Fly-by fix, we make LoggingPrefs::sGfxLogLevel as it is written on the main thread but read on different threads.
Differential Revision: https://phabricator.services.mozilla.com/D31460
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
This will allow to remove gfxPrefs later. On Windows in particular, the need to decide gfxPrefs vs StaticPrefs for the WMF decoders has caused several bugs in the past.
We will remove the confusion as a consequence.
Differential Revision: https://phabricator.services.mozilla.com/D30589
--HG--
extra : moz-landing-system : lando
Following the shift in unified build setup following the removal of gfxPrefs.{cpp,c} we hit this error.
Unified builds made this header get included with other files that use multiple inheritance, and clang-cl about the conflicting inheritance models. Local testing suggests clang-cl doesn't need the pragma anyway, so just take it out.
Differential Revision: https://phabricator.services.mozilla.com/D31465
--HG--
extra : moz-landing-system : lando
During the visibility pass, the main clip chain instance for each
primitive is created. In the prim prepare pass, a clip chain instance
is generated for each segment (of primitives that are segmented).
This previously required maintaining the active clip chain stack
during both passes. However, this is not ideal for a number of
reasons: the code is somewhat complicated / error prone and the
segment clip chain building step does more work than required.
This patch changes the segment clip chain building code to set up
the active clip nodes based on the result of the initial clip
chain built for the overall primitive during the visibility pass.
This means that it's no longer necessary to maintain the active
clip chain stack during the prepare pass. This simplifies some
upcoming picture caching changes related to avoiding redundant
cache invalidations, which is the main motivation for the change.
Differential Revision: https://phabricator.services.mozilla.com/D32250
--HG--
extra : moz-landing-system : lando
This is a follow-up to https://phabricator.services.mozilla.com/D30600
Previously, I changed changed the space mapper logic to use the world transformations.
This was seemingly needed because we requrested the relation between primitives and
their clip nodes, which could be in unrelated spatial sub-trees.
However, I believe the change was a mistake, since for clips we should not even try
to get the relative mapping, and clipping is done in world space for these cases.
This change reverts that logic back. ~~Fingers crossed for the try to not show any
asserts firing up inside get_relative_transform.~~ Try is green 🎉
Differential Revision: https://phabricator.services.mozilla.com/D32382
--HG--
extra : moz-landing-system : lando
These tests cause panics in debug mode because of the extra GL error
checking. Tests that are disabled are annotated with the failing
GL call.
Differential Revision: https://phabricator.services.mozilla.com/D32012
--HG--
extra : moz-landing-system : lando
This makes it so that when running reftests, wrench actually terminates
after a panic rather than just hanging. Termination is detectable and so
we can clean up properly instead of waiting until some other layer hits
a timeout.
Differential Revision: https://phabricator.services.mozilla.com/D32010
--HG--
extra : moz-landing-system : lando
The relevant definition in the spec;
https://drafts.csswg.org/css-device-adapt/#min-scale-max-scale
Before this change, if both of initial-scale and maximum-scale are negative,
both values are clamped to 0.25. Whereas with this change, negative scale
values are treated as if it's not specified so that initial-scale value is
automatically calculated based on the layout viewport size.
negative-initial-and-maximum-scale.html is a test case for the case.
Also with this change, initial-scale values are going to be clamped to the
range [0.25, 10] during parsing it so that initial-scale-0.html and
initial-scale-100.html need to be modified, now the former is scaled by 0.25x,
the latter is scaled by 10x.
(Before this change, initial-scale=0 and initial-scale=100 were treated as
invalid scale values in nsViewportInfo::ConstrainViewportValues[1])
[1] https://searchfox.org/mozilla-central/rev/6c9f60f8cc064a1005cd8141ecd526578ae9da7a/dom/base/nsViewportInfo.cpp#15,19
Differential Revision: https://phabricator.services.mozilla.com/D32098
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
StaticPrefs doesn't support nsCString type and the changes required to support this would be rather big. Seeing that there was only a single gfxPrefs using this, and this is a "Once" pref ; we move it to gfxVars instead.
Differential Revision: https://phabricator.services.mozilla.com/D31462
--HG--
extra : moz-landing-system : lando
Fly-by fix, we make LoggingPrefs::sGfxLogLevel as it is written on the main thread but read on different threads.
Differential Revision: https://phabricator.services.mozilla.com/D31460
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
