Now we can throttle some sort of animations which run on the main thread
as well as animations on the compositor. So, AreAsyncAnimationsEnabled checks
should be removed.
The check in PresShell::HandleEvent might be replaced with checking
nsIDocument::mNeedStyleFlush, but I am not sure.
In order to raise an assertion in CanIgnoreIfNotVisible() which will be
introduced in part 3 when the cumulative hint is not properly, we should skip
the calculation when mProperties is empty.
BuildSegmentsFromValueEntries now needs base nsStyleContext to calculate
the change hints.
If the change hint is not set correctly, we will check it in
CanIgnoreIfNotVisible() introduced in a subsequent patch (part 3).
* partially-out-of-view-animation.html
This test is a normal test case (i.e. a trivial one). An animation on an
element which is partially out of the view. If ofscreen optimization
is totally broken, this test will fail.
* in-visibility-hidden-animation-pseudo-element.html
This test checks animation on visible pseudo element which is attached to
invisible element is not throttled.
* in-visibility-hidden-animation.html
This test checks animation on visible element which is inherited from
invisible parent element is not throttled.
This currently can't happen as no MediaDataDecoder ever return a null sample.
MozReview-Commit-ID: BucIadubght
--HG--
extra : rebase_source : 4c6f3dc1d5581bdb9d58ba3b7cc1659c57f40d8e
If we're in waiting for data mode, the decoder must have already been drained and we want the waiting promise to be resolved upon the next run of UpdateReceivedNewData.
MozReview-Commit-ID: Hf8pFFyQmjJ
--HG--
extra : rebase_source : c51ed65c7d7c4a9ee877e6f9420f6534480e7cb5
Amendment to bug 1244410. If no frames had been output yet, last dts would have been INT64_MIN.
MozReview-Commit-ID: LOdWLpyuLYm
--HG--
extra : rebase_source : f842d2214b1e82f3b069e843157b95d87e62fa01
A bit of a shot in the dark, but it is possible that data got received but that information got lost as reset was called.
MozReview-Commit-ID: 1KjQeCFsGPJ
--HG--
extra : rebase_source : 3a522045bde0658fdfeccbf4d0cac11b43bc35d7
There was some mistake in patch of bug 694696 which incorrectly added
'skip-if' for some unrelated test. This patch reverts those mistakes in
addition to just moving the test back.
It also attaches the "fullscreen" tag to the test as it triggers that.
MozReview-Commit-ID: 2PMX6PFZWm2
--HG--
extra : source : f51c8dd75753ce5ef7d171b74f3f39fbd55ed38d
This commit does two things to speed up hashing in the
SharedImmutableStringsCache:
* We eagerly compute a string's hash when we create a lookup for it. This means
that we compute the hash before we take the lock, which reduces the length of
time the lock is held.
* For strings longer than SHORT_STRING_MAX_LENGTH (currently 8192), we only hash
the first N and last N characters in the string, where N =
SHORT_STRING_MAX_LENGTH / 2. This increases the risk of collisions, but in
practice it should be rare, and this yields a large speedup for hashing long
strings.
GetConsoleWindow() can return NULL. Previously, we may have passed a NULL
console reference into FlashWindowEx(). On my machine (when running in a
console), passing NULL doesn't seem to cause an error. But since we have
a report of this function hanging, it is quite possible it can cause
hangs in other scenarios. Since a NULL console won't result in any
notification, let's not call FlashWindowEx() when no console is available.
MozReview-Commit-ID: LrKX8weUkzX
--HG--
extra : rebase_source : 6c3fc724dbc038f6b51bbdc14d985202c47074e8
Before, ./mach build would try to use terminal-notifier after building, but would not be able to since it isn't installed.
MozReview-Commit-ID: 4oBAVfOdcNs
--HG--
extra : rebase_source : 0930e9d4dc038e59f18beb85b4911552c76c0eed
The condition will be perfectly handled by the MediaFormatReader anyway.
MozReview-Commit-ID: Dm6evq6T4t6
--HG--
extra : rebase_source : 6e49cfae68bfa856aad891faf3cea565b152e565
We added the code to hide the header in bug 1262214 but it went
inside a block that is only executed when we're changing views.
As a result, if we open the add-on manager looking at the discovery
page, the header isn't hidden. Fix it by making it unconditional.
MozReview-Commit-ID: 2PnW1F9aYgt
--HG--
extra : rebase_source : 31aa0079208e18575bc8af31a6cea224470c72e7
The label has been there for years. It isn't really experimental.
The Visual Studio solution still leaves a lot to be desired. But
let's not scare people away by calling it experimental.
MozReview-Commit-ID: 7UvsbsKNnWw
--HG--
extra : rebase_source : a7d3f824859629297a782a0883ebf78af1d8fa70
By using self._write_file() and FileAvoidWrite, we avoid writing files
unless they change. This means that Visual Studio won't want you to
reload the solution and projects whenever the backend is generated.
This means you can regenerate the backend all you want and chances are
it won't disrupt your Visual Studio experience.
Since self._write_file() creates parent directories for us, we were
able to remove this code.
If you run `mach build-backend --diff` with this commit, output will
change. For reasons I don't understand, we were producing XML with
e.g. \r\r\n sequences. This patch appears to restore \r\n. How
we got \r\r I don't know because I can't find anywhere in the code
where that can occur. But this commit does appear to restore sanity.
Also, it appears modern versions of Visual Studio (perhaps only VS2015)
doesn't write your project files. When I initially implemented Visual
Studio project generation several years ago, as soon as you loaded
the solution and hit "Save All" Visual Studio would re-save your files
using a slightly different formatting (it did some gnarly things with
XML indentation). VS2015 doesn't do this. So your files on disk should
be unmodified for longer, making Visual Studio a more viable development
environment. Yay.
MozReview-Commit-ID: 7CSk0dsLOli
--HG--
extra : rebase_source : 3cd04ba8ffed8fc8880de66b1f4fce1f6300b51c
Currently, self._write_file() instantiates FileAvoidWrite instances
with the default mode of 'rU' which uses universal newlines (\n).
Visual Studio project files use CRLF newlines. We want to use
self._write_file() in the Visual Studio backend (which predates
self._write_file). Prepare for this by passing the mode argument
through.
MozReview-Commit-ID: LHCUf3IrpJ8
--HG--
extra : rebase_source : be08d8e043ef625f8f846c38446e1430e072a665
If we're running VS2013, we generate VS2013 files. If we're running VS2015,
we generate VS2015 files. If we don't have a Visual Studio version
defined, refuse to generate project files (hopefully this doesn't
happen in the real world but I'm sure someone will complain if it does).
MozReview-Commit-ID: 5GdsbGmWPLB
--HG--
extra : rebase_source : 1a50c0fa5b7980ad25fb3ed3c1ec2c95f16996b6
We only support building with VS2013 and VS2015. Remove references
to older versions in the Visual Studio build backend.
MozReview-Commit-ID: 6QTSylqLwLF
--HG--
extra : rebase_source : d654f0e415dd5c1bfa1258633e26d467bea5535a
Call the device binding code in gtests, and have a test GMP which returns the
device ID it was passed in a message, so that we can verify that the id the GMP
was passed is the same as the id generated in the parent.
MozReview-Commit-ID: Gjqvo6dRK1D
--HG--
extra : rebase_source : bea5acc878a639fb819051e19e23533c14c19927
I want the EME device binding/nodeId code to be callable from gtests, as well
as in plugin-container. I need this because I want to add a gtest that ensures
that we don't regress the EME/GMP device binding code. I want to call the GMP
device binding code in the gtest and in the GMP process, and compare the
result.
So we need to make it possible to link the device binding code into the gtests
as well as plugin-container. So move all code that device binding calls into
librlz, to make it easier to link against all the code required.
Note: the device binding code needs to be statically linked into
plugin-container so that it's covered by the Adobe CDM's voucher tool.
MozReview-Commit-ID: AvBAe1dh49Z
--HG--
rename : ipc/app/sha256.c => dom/media/gmp/rlz/sha256.c
rename : ipc/app/sha256.h => dom/media/gmp/rlz/sha256.h
extra : rebase_source : f60f1e68649fa90cbe1f2fe09f5f69948444b1df
I want the EME device binding/nodeId code to be callable from gtests, as well
as from in plugin-container.
First step is to move the device binding code into a discrete file, so I can
also link that into gtests, and call it from there to compare the result with
what's in the GMP process.
MozReview-Commit-ID: 9xT2rp3hWW
--HG--
extra : rebase_source : 824c7a9841bce83c438decad48ce210f6c2a5571
Hiroyuki Ikezoe
Jean-Yves Avenard
Phil Ringnalda
Xidorn Quan
Xidorn Quan
Terrence Cole
Nick Fitzgerald
JW Wang
Gregory Szorc
Nathan Hakkakzadeh
Byron Campen [:bwc]
Andrew Swan
Shih-Chiang Chien
Benoit Girard
Chris Pearce