The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55443
--HG--
extra : moz-landing-system : lando
IDCompositionDevice is replaced by IDCompositionDevice2. It is necessary for IDCompositionDeviceDebug usage. And for using IDCompositionDevice2, _WIN32_WINNT and NTDDI_VERSION is updated from Windows 8 to Windows 8.1.
Workaround MinGW build failure.
Differential Revision: https://phabricator.services.mozilla.com/D47742
--HG--
extra : moz-landing-system : lando
This seems to make a big difference when running tests with WARP.
e.g. Assertion failure: frameInfo.mDocFramesSeen == frameInfo.mDocFramesTotal,
at z:/build/build/src/gfx/webrender_bindings/RenderThread.cpp:303
and various other browser chrome test failures.
The original problem that added this flag only impacted AMD hardware as I
recall and we are unlikely to ever be running on WARP in production anyways.
When WARP is forced we also don't disable INTERNAL_THREADING_OPTIMIZATIONS.
Differential Revision: https://phabricator.services.mozilla.com/D42214
--HG--
extra : moz-landing-system : lando
This makes us use the actual adapter description instead of a null one.
This fixes the problem of a mismatch being detected in ContentAdapterIsParentAdapter which
is using D3D11Checks::GetDxgiDesc to determine the adapter.
Differential Revision: https://phabricator.services.mozilla.com/D41804
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
Currently it's completely unclear at use sites that the getters for `once`
static prefs return the pref value from startup, rather than the current pref
value. (Bugs have been caused by this.) This commit improves things by changing
the getter name to make it clear that the pref value obtained is from startup.
This required changing things within libpref so it distinguishes between the
"base id" (`foo_bar`) and the "full id" (`foo_bar` or
`foo_bar_DoNotUseDirectly` or `foo_bar_AtStartup` or
`foo_bar_AtStartup_DoNotUseDirectly`; the name used depends on the `mirror` and
`do_not_use_directly` values in the YAML definition.) The "full id" is used in
most places, while the "base id" is used for the `GetPrefName_*` and
`GetPrefDefault_*` functions.
(This is a nice demonstration of the benefits of the YAML file, BTW. Making
this change with the old code would have involved adding an entry to every
single pref in StaticPrefList.h.)
The patch also rejigs the comment at the top of StaticPrefList.yaml, to clarify
some things.
Differential Revision: https://phabricator.services.mozilla.com/D38604
--HG--
extra : moz-landing-system : lando
The patch also removes the layers.mlgpu.enable-container-resizing pref, because
it's dead.
Differential Revision: https://phabricator.services.mozilla.com/D36159
--HG--
extra : rebase_source : e215d584aed18f865d2e8d00a78e76e9b0323e6e
Static VarCache prefs have setters. These are dangerous because they can
violate the primary invariant of VarCache prefs, which is that the global
variable always matches the pref value in the table.
Fortunately they are only used in tests, and we can use vanilla pref setters
instead, and get rid of the VarCache setters.
Differential Revision: https://phabricator.services.mozilla.com/D35632
--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
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
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 allows to more easily construct it and add new values as needed.
The other bool members could be made to be part of the set, but this would require more significant code change.
Depends on D8082
Differential Revision: https://phabricator.services.mozilla.com/D8129
--HG--
extra : moz-landing-system : lando
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant C++ functions are updated to take a typed enum. JavaScript
calls are unaffected but they will throw if the string argument does not
correspond to one of the known entries in the C++ enum. The existing whitelists
and blacklists of annotations are also generated from the YAML file and all
duplicate code related to them has been consolidated. Once written out to the
.extra file the annotations are converted in string form and are no different
than the existing ones.
All existing annotations have been included in the list (and some obsolete ones
have been removed) and all call sites have been updated including tests where
appropriate.
--HG--
extra : source : 4f6c43f2830701ec5552e08e3f1b06fe6d045860
CompositorBridgeChild may be lost at any time due to a GPU process
crash. Additionally it may be already destroyed due to shutdown being
initiated. For FlushAsyncPaints, we can safely ignore the missing child
because the subsequent operations will generally fail and we will
recover when the GPU process is respawned (or switched to the UI
process).
- As we are creating a separate VR process in Bug 1362578,
we will need our own D3D11Device.
- Eventually, we will be allowing the VR device runtimes to
help select the appropriate adapter / device based on the
physical connection. This function will be updated at that
time.
MozReview-Commit-ID: EewUkNxU3BI
--HG--
extra : rebase_source : d89dd4dcc71f2b0dc54711f50628ee3bc494b73e
There's no way to handle this failure, so pass it to Unused.
MozReview-Commit-ID: 37PS9TsPqx7
--HG--
extra : rebase_source : f385f4c50d5407b1929abed7dae123f9570d2205