To prevent new buffer object from being created per frame, either
Sample.CREATOR has to keep track of all buffers from every remote codec,
or the client must memorize seen buffers and avoid asking for them again
and again. The former saves client code from modifications but complicates
the implementation of Sample, a data structure class, while the latter
requires changes to client code but avoid overcomplicating Sample.CREATOR
implementation.
The 2nd approach is taken:
- move SampleBuffer out of Sample, and update clients accordingly
- add a new IPC method for clients to get the buffers only when needed
Differential Revision: https://phabricator.services.mozilla.com/D24590
--HG--
extra : moz-landing-system : lando
(The tests currently fail on macOS using mozilla CI because of the old version of macOS present there,
which has an emoji font that doesn't support some of these sequences. On macOS 10.13, the tests pass
as expected, so the failure annotations are temporary until the test environment is updated in bug
https://bugzilla.mozilla.org/show_bug.cgi?id=1530474.)
Depends on D25101
Differential Revision: https://phabricator.services.mozilla.com/D25102
--HG--
extra : moz-landing-system : lando
Replacing values defined as constants in Unicode.h in the CharacterEncoding.cpp file
Differential Revision: https://phabricator.services.mozilla.com/D24601
--HG--
extra : moz-landing-system : lando
We also allow leading and trailing spaces for pair to be consistent with length,
number, etc.
Differential Revision: https://phabricator.services.mozilla.com/D25050
--HG--
extra : moz-landing-system : lando
Ion can do aggressive inlining, but inlining a lot of code has a negative
effect on compilation time and memory usage. It also means we spend more time
in the slower Baseline code while compiling the Ion code off-thread or after an
invalidation.
To address this, Ion now consists of two tiers:
* Normal: the first tier (warm-up threshold of 1,000) only inlines small
functions one level deep. This tier also has recompile checks to
recompile the script when it becomes very hot.
* Full: the second tier (warm-up threshold of 100,000) is only used for very
hot code so we can afford inlining a lot more code.
This improves Speedometer and GDocs by more than 5%.
Differential Revision: https://phabricator.services.mozilla.com/D24159
--HG--
extra : moz-landing-system : lando
We also allow leading and trailing spaces for pair to be consistent with length,
number, etc.
Differential Revision: https://phabricator.services.mozilla.com/D25050
--HG--
extra : moz-landing-system : lando
Originally we stored the new information about installation defaults in
installs.ini since older versions of Firefox would throw away any new data in
profiles.ini any time they made changes to the profiles. That does however mean
we have to load two files on startup.
This changes things so that we save all the data in profiles.ini as well as a
version tag and still save the install data into installs.ini. An older version
will throw away the install data and version tag from profiles.ini but leave
installs.ini alone. On startup if the version tag is gone from profiles.ini then
we reload the install data from installs.ini and put it back into profiles.ini.
At some point in the future where we don't care about supporting older versions
of Firefox we can just drop installs.ini entirely.
A lot of the changes here involve moving to loading profiles.ini into an
in-memory ini, keeping it up to date and flushing it to disk. This means that we
no longer throw away any information in the ini file that this version does not
understand allowing the possibility of adding new data to this file in the
future.
Differential Revision: https://phabricator.services.mozilla.com/D22576
--HG--
extra : rebase_source : d00edf1ceb200a73a60bb1a90afabcdf95b01acf
extra : intermediate-source : e1c9790cd3bee060da99ffe37026721e36bc46c3
extra : source : d4feb17faf013134f5eac8b5e19b714c56410973
