When ffmpeg is enabled, it will use the FFmpeg's VPX decoder. FFmpeg appears to always buffer 15 frames before returning one (this is the same with h264) causing the waiting event to be fired much earlier than when using libvpx
We now use FFmpeg on linux to decode h264. This allows to pass all the mp4 tests.
FFmpeg (like windows 7) will buffer 15 frames prior outputting a frame which causes TIMEOUT as the media appended only contains 12 frames.
Instead of using long_press_without_contextmenu() with built-in long tap
injector in AccessibleCaretEventHub to select a word, we can use
DOMWindowUtis to send synthesized mouse long tap events to gecko. This
triggers the code path which is closer to the real events fired by APZ
on B2G.
This change also makes marionette tests cover the focus-changing code by
long tap in AccessibleCaretManager. This is subtle but significant since
it's possible to write focus changing tests via long tap now.
--HG--
extra : commitid : 88Mi3beYfSI
extra : rebase_source : e61d6341a88b56e1c186e53d361b46f35e78f758
This is for synthesizing mouse long tap in marionette test for
AccessibleCaret.
--HG--
extra : commitid : 88Mi3beYfSI
extra : rebase_source : 2879c690e2162ea9eb213db65a81278b11900b01
* Use word_location() and long_press_on_location() to implement
long_press_on_word.
* Use long_press_on_location() instead of
long_press_without_contextmenu().
--HG--
extra : commitid : 88Mi3beYfSI
extra : rebase_source : 5b11ccf4aafdee3686ddeab5dfefab2e0ecea84d
* Incorporate the for-loop in python into javascript so that we only
need to call execute_script() once.
* Add documentation for parameters.
--HG--
extra : commitid : 88Mi3beYfSI
extra : rebase_source : bcf949c8a6055cf6ccaf541f8005fe88256555be
* Eliminate the duplicated code for setting the preferences.
* Rename open_test_html() in test_selectioncarets2.py to
open_test_html_multirange() to avoid name collision.
--HG--
extra : commitid : 88Mi3beYfSI
extra : rebase_source : b0f79b4b2fe801074286682978105f1c3bcd39de
When inserting instructions that encode a pc-relative offset, don't use
a method that depends on getting a pointer to the newly inserted method.
Use the new nextinstrOffset() method when computing the encoding of the
pc-relative offset, and only insert each instruction once.
Propagate OOM from calls to buffer.allocEntry, folowing the approach in
the ARM assembler.
Compressing C++ unit tests is a long pole when writing test archives.
Experimenting with various levels of compression revealed that
compression level 9 was providing minimal space savings for
significantly longer archiving times and greater CPU usage.
Results of our experimentation of `make -sj8 package-tests` on OS X
with various levels of compression are below. Note: these numbers were
accidentally obtained without JS tests being archived. This skews the
results a little but doesn't impact the analysis below.
ARCHIVE SIZE WALL CPU
(L=9)
cppunittest 76,806,629 30.6s
mochitest 61,276,928 9.4s
reftest 31,204,396 11.0s
ALL 228,146,761 31.2s 75.9s
(L=8)
cppunittest 76,851,593 24.1s
mochitest 61,279,322 8.9s
reftest 31,207,867 10.4s
ALL 228,228,096 24.9s 64.7s
(L=7)
cppunittest 77,102,292 14.3s
mochitest 61,305,147 8.2s
reftest 31,260,359 9.4s
ALL 228,717,803 15.0s 49.1s
(L=6)
cppunittest 77,321,408 11.5s
mochitest 61,336,539 8.2s
reftest 31,303,604 9.2s
ALL 229,123,307 12.2s 44.7s
(L=5)
cppunittest 78,226,404 8.2s
mochitest 61,483,804 7.6s
reftest 31,509,349 8.8s
ALL 230,725,600 9.6s 39.7s
(L=4)
cppunittest 79,733,669 6.3s
mochitest 61,825,519 7.6s
reftest 31,924,171 8.4s
ALL 233,669,991 9.0s 36.4s
(L=3)
cppunittest 82,380,731 5.8s
mochitest 62,554,431 7.1s
reftest 32,696,415 8.1s
ALL 239,180,168 8.9s 34.6s
Levels lower than 3 resulted in larger archives with no decreae in
wall time and marginal decrease in CPU time.
As we can see, lowering the compression level reduces archiving time by
>3x while only increasing total archive size by ~2.5 MB or ~1% for
compression level 5.
Total time hits a plateau around levels 4 and 5. After that, file size
increases faster for little decrease in wall time. I suspect that we're
hitting Python limits from having to process thousands of files: there's
only so fast Python can do I/O and make function calls.
I think choosing 4 or 5 for the new compression level are acceptable.
I went with 5 because the wall time savings from 5 to 4 are marginal and
the archive size does start to increase a bit faster at 4. That being
said, 4 does consume 10% less CPU. I could easily just 4 as well. 5 is
more conservative. We can always change to 4 after seeing results in the
wild.
The end result of this change is `make package-tests` is much faster:
Before: 228,146,761 bytes; 31.2s wall; 75.9s CPU
After: 230,725,600 bytes; 11.4s wall; 45.0s CPU
Delta: +2,578,839 bytes; -19.8s wall; -30.9s CPU
When you take the whole series into consideration:
Before: 44.2s wall; 84.6s CPU
After: 11.4s wall; 45.0s CPU
Lowering CPU is impressive considering we switched from the C `zip`
implementation to Python!
Keep in mind we were at ~78s wall before e87b74b3db43 introduced
concurrent archive generation!
And we still haven't eliminated the staging of JS tests, which are
several thousand files and a few dozen MB!
--HG--
extra : commitid : D1fD4NUTw2F
extra : rebase_source : c6de72656cfedc98c0cf1c09eefe1dfb84f3639b
An upcoming commit will introduce a caller that doesn't want the maximum
compression level. This commit introduces arguments to control the
compression level inside written archives.
--HG--
extra : commitid : KkDso3hB2QG
extra : rebase_source : 8fd05aeae5c3555e1169eac6656d584007cd0739
Metrics are nice. Adding this output clearly demonstrates that C++ unit
tests are the long pole by far: they take ~95% of wall execution time
to archive (~30s total). The next longest archive only takes ~11s to
produce. This will be important if we ever want to reduce archive time
further on optimal hardware.
FWIW, disabling compression will produce a C++ unit test archive in
1.0s. Archives with more files take longer, despite the significantly
smaller sizes.
--HG--
extra : commitid : 6E56aUoZUL2
extra : rebase_source : 48cad51d7fbae883861f35e1b5cb96799b452bfb
Won't impact performance much. But fewer make foo makes porting the C++
unit tests (which are the largest remaining tests) to the Python
archiver easier to grok.
This conversion did change behavior slightly. Previously, startup
cache files weren't being packaged if startup cache was disabled. Now,
we always package them since their presence in the test archive should
be harmless. The original change to guard their inclusion in
ee82e0ae5488 was probably unnecessary.
--HG--
extra : commitid : AzU65j0E1q0
extra : rebase_source : 9b8a15dc1a5f3c3d3e453cefb3a99b05f5a77711
This prevents copying of 447 files adding to ~4 MB.
--HG--
extra : commitid : 7zTbiQeMQSQ
extra : rebase_source : b3ac223835ba7289ace45aa7d02c5a050d54cc0d
This saves copying of ~100 files comprising ~1 MB. Not significant. But
it gets us a little closer to no staging.
--HG--
extra : commitid : 6Hjnhv4Yi5R
extra : rebase_source : 291c89682a23cde957b3c68f2efe3b6dc3d3d543