JsonCpp is used in different places around Firefox, which is normally built
without exception handling, so we don't want JsonCpp to `throw`.
Because we don't want to modify the JsonCpp files themselves (to ease future
update from the source), and some of its headers are directly included around
Firefox, we need to define `JSON_USE_EXCEPTION` to be 0 everywhere, which can
be done through moz.configure.
JsonCpp replaces its exception-triggering code with C asserts and aborts.
Differential Revision: https://phabricator.services.mozilla.com/D151190
Caching the pref values at initialization instead of on demand allows
this code to be threadsafe and accessible from DOM workers.
Differential Revision: https://phabricator.services.mozilla.com/D151365
The loaders need to be destroyed on the main thread. Assertions for
gfxUserFontSet and gfxFontFamily need to be updated for workers.
Depends on D151342
Differential Revision: https://phabricator.services.mozilla.com/D151343
This is necessary for when we want to draw text with Canvas 2D and a
user font. This ensures the necessary font families are populated prior
to processing the text run.
Differential Revision: https://phabricator.services.mozilla.com/D151342
Some test failures suggest that somehow the main-thread pre-allocated buffer
was available, but not in-session (because its chunk manager pointer was null).
The code shouldn't allow this situation:
- EnsureBufferForMainThreadAddMarker() creates the buffer with a
non-fallibly-allocated chunk manager.
- ReleaseBufferForMainThreadAddMarker() destroys the whole buffer, including
its chunk manager.
- In GetClearedBufferForMainThreadAddMarker(), Clear() should not destroy the
chunk manager.
So this patch adds some more asserts, to verify my assumptions, and potentially
catch the issue closer to where it happens.
Differential Revision: https://phabricator.services.mozilla.com/D151351
When reading Dwarf unwind info, `CallFrameInfo::RuleMap::registers_` is a
`std::map<int, Rule>` used to map (Dwarf) register numbers to the current
unwind rule for each number. These mappings are very small (typically <= 7
elems) and very short lived. Result is that `std::map` creates a lot of
overhead because it is implemented as a Red-Black tree, and hence does a lot
of malloc/freeing of nodes.
This patch replaces it with a simple vector, wrapped up in a new `class
CallFrameInfo::RuleMapLowLevel`. Comments have also been improved. The
resulting performance changes are as follows:
user time insns #malloc #megabytes
seconds million calls allocated
x86_64 before 0.42 5609 5,891,857 560.8
x86_64 after 0.27 3906 894,188 323.1
arm64 before 0.46 7697 8,469,659 680.8
arm64 after 0.24 4922 1,043,154 427.1
x86_64: Intel Core i5 1135G7, 4.2GHz, Fedora 35
arm64: Apple M1, ??? MHz, Fedora 33 running on Parallels Workstation
Differential Revision: https://phabricator.services.mozilla.com/D151261
This patch move the ShouldApplyDelazificationStartegy as well as the
ApplyDelazificationStrategy under FillCompileOptionsForRequest.
As not all delazification strategies are capable of handling modules yet (Bug
1760334), and do not apply to cached-stencil, we have to add extra filters to
prevent ShouldApplyDelazificationStrategy to access custom delazification mode.
Differential Revision: https://phabricator.services.mozilla.com/D150118
Elements with display:contents does not participate in layout, but it's children does. When
calculating the bounding rect of a range, those children have to be taken into account.
Differential Revision: https://phabricator.services.mozilla.com/D151229
This fixes the original case by adding an extra error reason which is used when
the specifier could be bare and and only warning about relative URLs in this
case.
The same problem happens with import maps enable where "./foo.js" produces an
error about it being a bare specifier, which it's not. For that case make
ParseURLLikeImportSpecifier return a ResolveResult and use the same approach.
Differential Revision: https://phabricator.services.mozilla.com/D151153
The container is turned into a footer and moved outside of
its current parent so it always stick to the bottom.
CSS was tweaked to keep it nice.
Differential Revision: https://phabricator.services.mozilla.com/D151284
Sanitizer builds require unstable features from the rust compiler, and
the common way to achieve this is to use a nightly rust compiler,
which we had been doing for a while.
Later on, we also needed to use unstable features that actually require
some patches to both rustc and cargo to work properly for our needs, so
we switched to taking the source of a nightly rust compiler, patch and
build it, and use that.
But finding an appropriate nightly rust compiler is not always easy. We
want something close enough from the stable rust compiler we're using
otherwise, which we've been using the first nightly that has the
following version number for. But it also can happen that those versions
have bugs that have been fixed later and then uplifted during the beta
period (and thus fixed in the stable rust compiler).
On the other hand, taking the source of the stable rust compiler and
compiling it with a `channel` set to `dev` (actually the default) or
`nightly` yields a compiler that is very close to the actual stable rust
compiler, but acts like a nightly compiler and allows to enable unstable
features.
So instead of trying to pick a good version from the nightly channel,
just use the same version as the stable rust version we use.
Differential Revision: https://phabricator.services.mozilla.com/D151341
Inspired by emilio's suggestion in the shader module API patch. This tries to be the most straightforward way to go from the strings coming from IPC to the ones consumed by wgpu.
Differential Revision: https://phabricator.services.mozilla.com/D151024
This patch is a lot of plumbing for not that much functionality. The goal is to align CreateShaderModule's error reporting with the spec.
Creating a shader module is now a dedicated async IPDL message returning the compilation info so that it can be exposed as a promise by the WebGPU API.
Differential Revision: https://phabricator.services.mozilla.com/D146817
This is done by adding `color-mix` to `COLOR_TAKING_FUNCTIONS`.
Test case is added, alongside with cases for other functions in which we
should show color swatches.
Differential Revision: https://phabricator.services.mozilla.com/D151224
If dedicated thread for out-of-process WebGL exists, compositor thread tasks are not delayed by WebGL tasks.
And Bug 1712486 requests that WebGL run on non-compositor thread.
Differential Revision: https://phabricator.services.mozilla.com/D151210
This will require that entries for renamed files be updated so that they don't
accidentally start being loaded under the new name later. It also prevents
dead code entries from sticking around after their targets are removed.
Using `throttledMapPromises` is probably not strictly necessary given the
small number of entries in most lists, but since it already exists, we may as
well use it here.
Differential Revision: https://phabricator.services.mozilla.com/D150921
This will require that entries for renamed files be updated so that they don't
accidentally start being loaded under the new name later. It also prevents
dead code entries from sticking around after their targets are removed.
Using `throttledMapPromises` is probably not strictly necessary given the
small number of entries in most lists, but since it already exists, we may as
well use it here.
Differential Revision: https://phabricator.services.mozilla.com/D150921
