Automatic conversion (say from int to bool) makes DecoderParam difficult to extend.
MozReview-Commit-ID: G0T7jPogskN
--HG--
extra : rebase_source : 59437fd2b430ccd6be50b18c98b5a5c4ed2c8240
We have about 11,500 of these when loading gmail in a Stylo-enabled build, from
SpecifiedUrls; the objects themselves account for about 1.3 MiB of memory, and the
strings within them about 2.9 MiB.
We also have a very small number of them on the Gecko side.
MozReview-Commit-ID: AduCIaDIzGG
--HG--
extra : rebase_source : ee2a20921a17b9091b60a5d9e389a6c6f2fa192b
We have about 11,500 of these when loading gmail in a Stylo-enabled build, from
SpecifiedUrls; the objects themselves account for about 1.3 MiB of memory, and
the strings within them about 2.9 MiB.
We also have a very small number of them on the Gecko side.
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because tested on Gecko side.
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: db689094f1413f542961cbe0d19a3ed82a11f682
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : ef3e7f77133cb4b5e353de277c9a6332c1c5c7ec
In bug 1361258, we unified the initialization sequence on mac, and
chose to make the zone registration happen after jemalloc
initialization.
The order between jemalloc init and zone registration shouldn't actually
matter, because jemalloc initializes the first time the allocator is
actually used.
On the other hand, in some build setups (e.g. with light optimization),
the initialization of the thread_arena thread local variable can happen
after the forced jemalloc initialization because of the order the
corresponding static initializers run. In some levels of optimization,
the thread_arena initializer resets the value the jemalloc
initialization has set, which subsequently makes choose_arena() return
a bogus value (or hit an assertion in ThreadLocal.h on debug builds).
So instead of initializing jemalloc from a static initializer, which
then registers the zone, we instead register the zone and let jemalloc
initialize itself when used, which increases the chances of the
thread_arena initializer running first.
--HG--
extra : rebase_source : 4d9a5340d097ac8528dc4aaaf0c05bbef40b59bb
We try to find fix_macosx_stack.py on the wrong path, which leads us can't run
wpt tests without setting stack fix directory manually (--stackfix-dir).
In this patch, we fix this issue by pointing the path to @topobjdir/dist/bin.
MozReview-Commit-ID: 8JzWWgVM6fM
--HG--
extra : rebase_source : a7822998d7668b976284852bdca86e70d615b611
So we don't have to look at GetOffset(). We want to reduce the use of
MediaCacheStream::mChannelOffset so it is easier to fix data races about it.
MozReview-Commit-ID: 3GAbKYA9xi4
--HG--
extra : rebase_source : bfaceb190da30e3276085fb7930468ad51e3a98f
There is a lot of churn involved in adding new API surface to
mozjemalloc, and mozmemory.h is one. Instead of declaring
everything manually in there, "generate" the declarations through
malloc_decls.h.
--HG--
extra : rebase_source : 1416fa972319c419112c4a8b16759d90692db5b2
The TestTrackEncoder file only contained audio encoder tests. This makes the
distinction between the already existing TestVideoTrackEncoder and these audio
tests clearer.
MozReview-Commit-ID: KmM616S72Gm
--HG--
rename : dom/media/gtest/TestTrackEncoder.cpp => dom/media/gtest/TestAudioTrackEncoder.cpp
extra : rebase_source : abd0965fd27ef0f51575ac20e908b4cc908bca47
The AudioTrackEncoder has logic to attempt to init when given an AudioSegment.
This logic has previously been part of NotifyQueuedTrackChanges. This
changeset moves the logic to its own method. This allows for finer testing of
the init attempt behaviour.
MozReview-Commit-ID: Der1iM9J8fr
--HG--
extra : rebase_source : bb47dd483d69349482a6d8882e9768b1a8d09480
Also fix Bug 1399686 - `make package` broken on macOS after landing of bug 1399226
MozReview-Commit-ID: HVZ02HlV1b6
--HG--
extra : rebase_source : 4661571dacaaf10050be4fb859533d6d81a7529b
There's only one interesting case here: the active tab. When rendering the label
of an overflowing active tab into the fadeout mask surface, text rendering must
not use the font smoothing background color for dark vibrancy. Instead, it needs
to use the color of the tab itself for best results.
Alternatively, we could set the font smoothing background color of the active
tab to "transparent", because this text is not on top of a vibrant background.
However, doing so would lose the subpixel AA and would not look as crisp.
MozReview-Commit-ID: 28MKCz1vmb9
This property accepts a color. It's inherited and defaults to transparent.
Its value is respected on macOS when rendering text into transparent pixels.
This property should be used for text that is placed on top of "vibrant"
-moz-appearances, in order to achieve high quality text rendering for such text.
In most cases, the property should be set to a named system color; an upcoming
patch in this patch series will add one such color for each vibrant
-moz-appearance value.
However, in some cases it can also be useful to use a custom color: If text
is rendered into an intermediate surface, for example because a mask is applied
to it, and the background color behind that intermediate surface is known, then
this property can be set to that background color in order to achieve subpixel
AA for the text inside the mask effect. In that case, the font smoothing
background color is respected because text is rendered into transparent pixels
*inside the intermediate surface*. At the moment, the only example of that use
case is the text of the active tab in the state where the text is overflowing.
MozReview-Commit-ID: D98qQnxoFaq
Jean-Yves Avenard
Nicholas Nethercote
Andrew Swan
Shane Caraveo
Anthony Ramine
Phil Ringnalda
Mike Hommey
Jeremy Chen
JW Wang
Thom Chiovoloni
Bryce Van Dyk
Felipe Gomes
Andy McKay
Servo VCS Sync
Matt Brubeck
Ed Lee
Fernando Jimenez Moreno
Jonas Finnemann Jensen
Sebastian Hengst
Emilio Cobos Álvarez
ffxbld
Ryan VanderMeulen
Philippe Normand
Alex Chronopoulos
Michael Layzell
Ted Campbell
Markus Stange