Sphinx has been complaining about a number of reStructuredText warnings
for a while. Fix all the ones in .rst files.
Not asking for review because this is docs only and changing .rst files
can't break anything important.
DONTBUILD (NPOTB)
For some reason the current code is resetting it twice - once explicitly and
once with the AutoSetOnScopeExit. To make matters worse, we have a monitor drop
between the two. So when DecodeSeek runs on the decode task queue but SeekCompleted
runs on the state machine thread, we can start another DecodeSeek during the monitor
drop, and then clobber it with the AutoSeetOnScopeExit, causing us to hang.
This is a non-issue with the patches in bug 1135170, but necessary to make the
patches in this bug independently green.
This already gets incoded in the DECODER_STATE_DORMANT case of RunStateMachine,
which will run momentarily on the state machine thread. Doing this allows us to
avoid calling StopPlayback on the main thread.
This is necessary because we're going to want to start disconnecting sample
and seek requests directly from the state machine thread, and the machinery
asserts that disconnection happens on the same thread as resolution.
More generally, this is the right thing to do architecturally, and will help
wean us off the monitor.
The current situation is really dangerous because it compiles on release builds,
but just lies. This bit me when I tried to use it for non-assertion purposes.
My reading of the reasoning for the current setup in bug 968016 is that we didn't
trust nsIEventTarget::IsCurrentThreadOn or thought it might be slow. But the
implementation of MediaTaskQueue::IsCurrentThreadIn doesn't actually use that, and
indeed currently does all of the work for this feature in release builds anyway.
Now that we have a mechanism for defining file-based metadata, let's add
a mach command to interface with it.
Currently, we limit ourselves to simple Bugzilla data dumping. Features
will be added over time.
--HG--
extra : rebase_source : 8f6c150f2f284097829aa495b4a043827fa5c8cd
extra : histedit_source : 41c71d0e9b20c73fc7524fd266e16bc7789ff463
This patch defines bug components for code that I have historically
touched.
--HG--
extra : rebase_source : 738916cf41ac11c094f5c15667925a7221e6446e
extra : histedit_source : 0f7d5cd869a7b239def58877a8858159219cdf59
The Files sub-context allows us to attach metadata to files based on
pattern matching rules.
Patterns are matched against files in a last-write-wins fashion.
The sub-context defines the BUG_COMPONENT variable, which is a 2-tuple
(actually a named tuple) defining the Bugzilla product and component for
files. There are no consumers yet. But an eventual use case will be to
suggest a bug component for a patch/commit. Another will be to
automatically suggest a bug component for a failing test.
--HG--
extra : rebase_source : 0f4004d364f6c2fe2b7f306823cb94313f4ebfe5
extra : histedit_source : 2beea807a122e08ba152a37beec2fcbe80981b64
We want the ability to read data from any moz.build file without needing
a full build configuration (running configure). This will enable tools
to consume metadata by merely having a copy of the source code and
nothing more.
This commit creates the EmptyConfig object. It is a config object that -
as its name implies - is empty. It will be used for reading moz.build
files in "no config" mode.
Many moz.build files make assumptions that variables in CONFIG are
defined and that they are strings. We create the EmptyValue type that
behaves like an empty unicode string. Since moz.build files also do some
type checking, we carve an exemption for EmptyValue, just like we do for
None.
We add a test to verify that reading moz.build files in "no config" mode
works. This required some minor changes to existing moz.build files to
make them work in the new execution mode.
--HG--
extra : rebase_source : 2f39e19c2eb11f937da85d41b9a514ca810d6be0
extra : source : af07351bf2d6e85293ae3edf0fe4ae6cbc0ce246
moz.build files should execute in filesystem traversal mode. Add a test
that verifies this is true.
This test performs a brute force filesystem scan to find relevant
moz.build files. This can be a little slow. That's unfortunate. But it's
a price we need to pay in order to ensure metadata extraction mode
continues to work.
--HG--
extra : rebase_source : 1b8a7110505a9b196b9b349103b581d2aeb8ddbe
Building on top of the API to retrieve relevant moz.build files for a
given path, we introduce a moz.build reading API that reads all
moz.build files relevant to a given set of paths. We plan to use this
new API to read metadata from moz.build files relevant to a set of
files.
This patch changes the generator behavior of read_mozbuild to emit the
main context before any processing occurs. This allows downstream
consumers to manipulate state of the context before things like
directory processing occurs. We utilize this capability in the new
reading API to forcefully declare the directory traversal order for
processed moz.build files, overriding DIRS and similar variables.
Since variable exporting doesn't work reliably in this new traversal
mode, variable exporting no-ops when this mode is activated.
--HG--
extra : rebase_source : 37e5d76bdcb1a626645bc0440994a3759571b578
Currently, MozSandbox assumes that the FUNCTIONS, SPECIAL_VARIABLES, and
SUBCONTEXTS data structures are the instances that should be associated
with the sandbox. As we introduce new moz.build processing modes that
wish to change processing behavior, it is necessary for them to have
control over these special symbols.
This patch moves the declaration of these types to the special metadata
dictionary which is inherited during recursion. The "read_topsrcdir" API
now explicitly passes the initial metadata into "read_mozbuild".
--HG--
extra : rebase_source : c09d9b9b4c20554c4d380148822f36200b89ecf4
An upcoming patch introduces a use case for a strongly typed named
tuple. So, we introduce a generic factory function that can produce these
types.
--HG--
extra : rebase_source : 4c04dcb511499fc4741f4da88472054b037abbed
We have an eventual goal to store file-level metadata in moz.build files
and to have this metadata "cascade" down directory hierarchies. e.g.
metadata in the root directory will apply to all children directories.
A prerequisite for this feature is a way to query which moz.build files
are relevant to a given file. In this patch, we implement an API that
returns this information.
--HG--
extra : rebase_source : 294c9e5fe0be7a5e34803e693f5927c06eeee044
With some GPUs (such as Intel HD-x000), Apple VideoTool box provides poor
decoding speed, causing us to drop frames for most HD videos.
VDA is around 50 times faster on those machines (31ms average to decode a 4K
frame with VT, while 0.6ms average with VDA)
Jon Coppeard
Mats Palmgren
Nigel Babu
Benjamin Bouvier
Julian Seward
Gregory Szorc
Anthony Jones
Bobby Holley
Chris Pearce
Jean-Yves Avenard
Mike Hommey
Brian Hackett
Chris Peterson