This remotes the APZInputBridge interface over the PAPZInputBridge
protocol in the case of the GPU process, and makes the GPU process'
main thread act as the APZ controller thread in that process. If
there is no GPU process we continue as before and the APZInputBridge
interface implementation is the concrete APZCTreeManager instance
in the UI process.
The main changes in this patch are moving all the code associated with
these messages out of APZCTreeManager{Parent,Child} and into
APZInputBridge{Parent,Child}. APZCTreeManagerChild now returns an
APZInputBridgeChild instance via InputBridge(), instead of returning
itself. The SetControllerThread call in the GPU process is also updated.
MozReview-Commit-ID: M4AaIW1Q0h
--HG--
extra : rebase_source : e5a8f14e23be34229fe80a47f6789d19b19e0a9f
This code is unused now that ReadLockDescriptors are not sent in layer transactions.
--HG--
extra : rebase_source : 8cd25541b22c3151e2dbd2f8ea6d1119e2f26c94
extra : source : 99a2d26d1ba82ad34a6c27641500a424cda015c3
This is important as these includes are often used to define ParamTraits
implementations which are needed to serialize struct members and
parameters. The place where the code which uses these implementations
will be moving from the protocol where they are used to the file where
the structs are defined, which means we need to includes these files
there.
MozReview-Commit-ID: H1wqgyv5mel
The FunctionBroker actors allow the NPAPI process (child) to run methods on the main process (parent). Both the parent and the child run dedicated threads for this task -- this is a top-level protocol.
inline is never set so cgen never emits inline.
MozReview-Commit-ID: BDL6BV8906t
--HG--
extra : rebase_source : aa51cda34db36ba08622d9940402cea14617c74a
never_inline is never set so cgen never emits MOZ_NEVER_INLINE.
MozReview-Commit-ID: HS7qw7D4lBC
--HG--
extra : rebase_source : 2eae9e3a7a0c95d94986283fabe670d5decec3c3
pure or override implies virtual. static is mutually exclusive with virtual (and pure and override). Combining these types into a "method specifier" enum simplifies the code and prevents bogus states like virtual=0 and pure=1.
MozReview-Commit-ID: IFeuvbp1RIo
--HG--
extra : rebase_source : d423d168a8b3a3d60cabd0f5e58fd03c6f655baf
This removes an unnecessary level of indirection by replacing all
nsStringGlue.h instances with just nsString.h.
--HG--
extra : rebase_source : 340989240af4018f3ebfd92826ae11b0cb46d019
Also ensure we're more consistent about having two blank lines after these methods.
MozReview-Commit-ID: 2SXXjDuMW4u
--HG--
extra : rebase_source : 05279ceab3aa32d1e577ea02ccd113180bb55792
There's already a typedef for MessageChannel, so use that instead of
Channel. Also, use IProtocol and not ProtocolBase or ChannelListener,
for simplicity.
MozReview-Commit-ID: 2zCjTpPTW4L
--HG--
extra : rebase_source : eed8d6d51a512ac85f6b4962fc12591bf81c2981
This method is now trivial, so we can inline a few things. This
removes the only callers of sendSems(), so remove that, too.
MozReview-Commit-ID: Bb4EF9M56ut
--HG--
extra : rebase_source : dedf31aa225361e31122362aefc76940edbf25f3
Currently if you write an async IPDL method which has a return value, we expose
a SendXXX method which returns a MozPromise. This MozPromise can then be
->Then-ed to run code when it is resolved or rejected.
Unfortunately, using this API loses ordering guarantees which IPDL provides.
MozPromise::Then takes an event target, which the resolve runnable is dispatched
to. This means that the resolve callback's code doesn't have any ordering
guarantees relative to the processing of other IPC messages coming over the same
protocol.
This adds a new overload to SendXXX with two additional arguments, a lambda
callback which is called if the call succeeds, and a lambda callback which is
called if the call fails. These will be called in order with other IPC messages
sent over the same protocol.
MozReview-Commit-ID: FZHJJaSDoZy
And remove unreachable code after MOZ_CRASH().
MozReview-Commit-ID: 6ShBtPRKYlF
--HG--
extra : rebase_source : 0fe45a59411bda663828336e2686707b550144ae
extra : source : 8473fd7333d2abe1ea1cc176510c292a5b34df45
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
Never store names in Message. One can get string names from
Message::name() or use IPC::StringFromIPCMessageType() when only
message id is available.
MozReview-Commit-ID: 15ksx6SE90c
--HG--
extra : rebase_source : 1a041dc365b7f42edd540d8c7a4dfd8912e48921
Each protocol in IPDL has a bunch of autogenerated functions that
instantiate IPC::Message with various parameters. Each of these
functions, then:
1) Pays the cost of calling malloc()
2) Setting up various parameters
3) Calling IPC::Message()
There's no reason that we should be duplicating 1) across all of these
autogenerated functions. In step 2), several of the parameters we're
setting up are common across all or nearly all calls: the message
segment size is almost always zero, and we're always indicating that
IPDL-generated messages should be recorded in telemetry.
Instead of duplicating that code several thousand times, we can add a
small helper function that takes the only interesting parameters for an
IPDL message. This helper function can then deal with calling malloc in
a single place and setting up the common parameters. For messages that
require a custom segment size, we'll have to use the old scheme, but
such messages are uncommon.
The previous changes are not required for this scheme to work, but they
do help significantly, as the helper function (Message::IPDLMessage) can
now take four parameters, which ensures that its arguments are passed
solely in registers on Win64 and ARM. The wins from this change are
also larger than they would be without the previous parts: ~100K on
x86-64 Linux (!) and ~80K on ARM Android.
The current IPC::Message constructor takes a large number of arguments,
three of which--the nesting level, the priority, and the
compression--are almost always constant by virtue of the vast majority
of Message construction being done by auto-generated IPDL code. But
then we take these constant values into the Message constructor, we
check them for various values, and then based on those values, we
perform a bunch of bitfield operations to store flags based on those
values. This is wasted work.
Furthermore, for replies to IPDL messages, we'll construct a Message
object, and then call mutating setters on the Message object that will
perform even more bitfield manipulations. Again, these operations are
performing tasks at runtime that are the same every single time, and use
information we already have at compile time.
The impact of these extra operations is not large, maybe 15-30K of extra
code, depending on platform. Nonetheless, we can easily make them go
away, and make everything cleaner to boot.
This patch adds a HeaderFlags class that encapsulates all the knowledge
about the various kinds of flags Message needs to know about. We can
construct HeaderFlags objects with strongly-typed enum arguments for the
various kinds of flags, and the compiler can take care of folding all of
those flags together into a constant when possible (and it is possible
for all the IPDL-generated code that instantiates Messages). The upshot
is that we do no unnecessary work in the Message constructor itself. We
can also remove various mutating operations on Message, as those
operations were only there to support post-constructor flag twiddling,
which is no longer necessary.
There's no need to be repeating 'IPC::Message::' prefixes or spreading
around more ExprVar calls than we need here. Let's try to improve the
signal-to-noise ratio of this code by introducing a helper function to
inject some of the boilerplate for us.
_generateMessageConstructor takes a lot of `md.FOO`-style parameters,
which could be derived inside the function by simply passing `md`.
Especially with the upcoming changes to calculate things like reply-ness
of messages, sync-ness, etc, we'd be wanting to pass even more
parameters like `md.FOO`. So let's just pass `md` in, and then we can
make all the necessary future changes in a single place.
The nsIU2FToken and its implementors are no longer needed; the soft token was
re-implemented into dom/webauthn/U2FSoftTokenManager.cpp during the WebAuthn
implementation. When the dom/u2f/ code changed to the implementation from
WebAuthn, the old synchronous version became dead code.
This patch removes the dead code.
MozReview-Commit-ID: 2yDD0tccgZr
--HG--
extra : rebase_source : 0f14d8de8f62599a41c13aa4d8fc9cdbc1fd79c7
The nsIU2FToken and its implementors are no longer needed; the soft token was
re-implemented into dom/webauthn/U2FSoftTokenManager.cpp during the WebAuthn
implementation. When the dom/u2f/ code changed to the implementation from
WebAuthn, the old synchronous version became dead code.
This patch removes the dead code.
MozReview-Commit-ID: 2yDD0tccgZr
--HG--
extra : transplant_source : %B3%96Te%E7%02%08%98%1A%B2%FA%1C%40%C4J%BC%B2%85j%81
Ted Mielczarek
Kartikaya Gupta
Ryan Hunt
Nika Layzell
Nathan Froyd
Noemi Erli
David Parks
Chris Peterson
Sylvestre Ledru
Eric Rahm
Ben Kelly
Andrew McCreight
Jeff Muizelaar
Gabriele Svelto
shindli
sotaro
Nicholas Nethercote
Gian-Carlo Pascutto
Benjamin Smedberg
Kan-Ru Chen
J.C. Jones
Phil Ringnalda