These methods are already guaranteed to be called on the controller
thread.
MozReview-Commit-ID: 4pfUZe6cI8e
--HG--
extra : rebase_source : 9ad24c0bb2e45bbd63e0a2febc14391e1a28f274
Currently the ZoomToRect function is only ever called on Android, on the
UI process main thread, which is neither the controller nor the sampler
thread. Instead of allowing "random" threads to run inside APZ, we
ensure that callers run it on the controller thread.
MozReview-Commit-ID: 64LkHaFLIOl
--HG--
extra : rebase_source : 61f397c0e18f83c68c228879692c9d4767b25675
Without this patch, UpdateZoomConstraints can get called on:
a) the compositor/sampler thread (over PAPZCTreeManager)
b) the controller thread which is also the UI process main thread (on
desktop platforms without a GPU process)
c) the UI process main thread when it's *not* the controller thread (on
Android).
Instead of having to reason about all these scenarios separately, we can
try to unify them a little bit by ensuring the function contents always
run on the sampler thread, which is the thread that seems to make the
most sense for it.
MozReview-Commit-ID: 8V4WTNtST3d
--HG--
extra : rebase_source : c4ebda75657d906d318acc07c174e8f3f634d18f
These two functions (UpdateWheelTransaction and ProcessUnhandledEvent)
are only ever called on the concrete APZCTreeManager when the APZ code
is living in the GPU process. This is because the calls are made by the
IAPZCTreeManager implementation which lives in the UI process, and
remoted over PAPZCTreeManager. So the assertion is safe, and will help
us guard against inadvertent breakage when we try making a different
thread the controller thread in the GPU process.
In addition, the WillHandleInput function can be called in the GPU
process on the compositor thread, but we will allow it to be called on
the main thread as well. In that case we need to ensure we don't try
running EventStateManager pref-reading code in the GPU process, and
instead preserve the current behaviour of just returning true.
MozReview-Commit-ID: JFBX3NSXywn
--HG--
extra : rebase_source : 6718944034ec7b7223581e562aa59e9e79b54b53
This function is never actually called over IPDL. It is called directly
on the concrete APZCTreeManager instance by the
AndroidDynamicToolbarAnimator code, both of which live in the
compositor. So we don't need to expose this method on IAPZCTreeManager
or over PAPZCTreeManager.
MozReview-Commit-ID: 6fEkJpDDvhl
--HG--
extra : rebase_source : cff9bb8fa43698950388b77f782b0b3fe6ec119b
Since we can have multiple browser windows on multiple different
displays with different DPIs, it doesn't make sense to have a single
static DPI value shared across all APZCTreeManagers. Instead, each
APZCTM should store its own DPI value for the display the window is on.
Since the DPI is only ever read from the controller thread, we can make
it bound to that thread, and update the setter code to also set it on
that thread.
As with the previous patch, the change in APZCTreeManagerParent is a
no-op but allows making some other thread in the GPU process the controller
thread. And the change in nsBaseWidget is a no-op everywhere except
Android.
MozReview-Commit-ID: CB23MxGISeL
--HG--
extra : rebase_source : b3358202ec5fa27422c56ae1b0b2237dbc8e489b
- The change in APZCTreeManagerParent is functionally a no-op because it
only ever runs in the GPU process on the controller thread. But it
allows moving the controller thread to some other thread.
- The change in nsBaseWidget is a no-op for desktop platforms, because
in the UI process the main thread is the controller thread. But on
Android it moves the call from the main thread to the Java UI thread.
MozReview-Commit-ID: LVVZLFxSuyj
--HG--
extra : rebase_source : 89e9c8824c31867ad92152ff9b496744a6afdd83
This code is unused now that ReadLockDescriptors are not sent in layer transactions.
--HG--
extra : rebase_source : 8cd25541b22c3151e2dbd2f8ea6d1119e2f26c94
extra : source : 99a2d26d1ba82ad34a6c27641500a424cda015c3
There can be something shuffling the iframe between the mouse event is sent and
the mouse event is received which makes us end up targeting the <body> instead
of the test target.
This can be reproduced with enough persistence either with and without the
patches from bug 1439875, at least on a headless build with rr chaos mode.
Move it to test_group_pointerevents in the apz tests to run it in a new window
and make it a bit more reliable.
MozReview-Commit-ID: BS6Es8iEmMY
- gfxVRExternal Enables other processes to present
real or simulated VR hardware to Firefox.
- This functionality is disabled by default, under
dom.vr.external.enabled.
- VRDisplayInfo, VRControllerInfo, and associated
structs have been restructured to ensure internal
state is not exposed via shmem interface.
- Some refactoring to convert structs to
POD types, enabling them to be located
in shmem and be memcpy'd.
- Work needed before unpreffing marked
with "TODO" comments.
MozReview-Commit-ID: FbsusbxuoQ8
--HG--
extra : rebase_source : 8a448169c3f47411c705a4d9fd462a1f9363dfd9
extra : amend_source : e6702549527292e2850d16e8f503f0be9848159f
In each case, the atom had an obvious name and a weird name. Where possible, I
kept the obvious name and commented out the weird name, viz:
- `mixed` over `_mixed` for "mixed"
- `el` over `el_` for "el"
- `other` over `other_` for "other"
- `remote` over `Remote` for "remote"
But for several of them I didn't do that, because the weird name is used
within the HTML5 parser -- which is a huge pain to modify because it involves
code generated by code from another repo -- so I kept the weird name and
commented out the obvious name, viz:
- `list_` over `list` for "list"
- `svgSwitch` over `_switch` for "switch"
- `set_` over `set` for "set"
MozReview-Commit-ID: Jp3CpdWXNDm
--HG--
extra : rebase_source : 421ce5316772f1951488307e81f2ceee696d363d
If we can assume that a layer being composited has an APZC at index i if and
only if the frame metrics at index i is scrollable, then we can do the
transformations in the next patch without any change in functionality.
MozReview-Commit-ID: FRkvhwdd3nh
--HG--
extra : rebase_source : f1bee292305730079b3208e447330028c1a40727
This makes more sense in APZCTreeManager, but is exposed back to
AsyncCompositionManager via APZSampler. This also makes the APZ code
better encapsulated since the method API exposed on APZSampler doesn't
need to take a AsyncPanZoomController; it can just take the
LayerMetricsWrapper instead.
MozReview-Commit-ID: 9yJJd3x8VhN
--HG--
extra : rebase_source : b6f81116183810df158d8cce72891bb2db458355
This should help us narrow down what's going wrong a bit.
MozReview-Commit-ID: 2Ah0nMCwv55
--HG--
extra : rebase_source : fae57d36fe28b364fc652fb0e32abbbf8da43b0e
If the GPU process restarts, the mLastAPZProcessedEvent gets reset to 1.
The code in Update() checks for this special case and resets the value
to the incoming content process sequence number. However, we before that
first call to Update() on the sampler thread, the FocusState might get calls
to ReceiveFocusChangingEvent(), which would be triggered by input events on
the controller thread. These input events would advance
mLastAPZProcessedEvent which would bypass the special case handling in
Update(). This can leave mLastAPZProcessedEvent at a lower value than
mLastContentProcessedEvent which triggers assertion failures.
This patch ensures that calls to ReceiveFocusChangingEvent() during this
initial state doesn't increment mLastAPZProcessedEvent, and so allows
the special case handling in Update() to work as expected. It also adds
the special case handling to the branch where the first Update() call
results in no focus target being selected.
MozReview-Commit-ID: 7P2O2qg0mXj
--HG--
extra : rebase_source : eb0655225eba55a7b1ad9bf16c7c8ecab3c0cc7b
Scrollable doesn't mean exactly the same thing as wheel-scrollable.
However, AsyncPanZoomController::CanScroll(const InputData& aEvent) mistakenly
calls CanScrollWithWheel without distinguishing between wheel scrolling and
non-wheel scrolling, which may potentially lead to wrong APZC targets during the
hittesting stage.
MozReview-Commit-ID: 6xXQdtObLwB
--HG--
extra : rebase_source : 1f4ee06b7d41213b2d6d85cdd1439a11b92b0e98
This changes the lifecycle and API for TextureReadLock to fix file descriptor exhaustion
crashes. These changes are partially superficial and mostly align the API of TextureReadLocks
with their actual usage.
The changes are:
1. Create the TextureReadLock in the TextureClient constructor so it's available before IPC creation
a. This is superficial as EnableReadLock was always called before IPC creation
2. Send the ReadLockDescriptor in the PTextureConstructor message and close the file handle
3. Receive the ReadLockDescriptor in TextureHost and close the file handle
4. Send a boolean flag in layer transactions if the texture is read locked instead of a descriptor
5. Use a boolean flag in TextureHost to determine if the ReadLock must be unlocked instead of a nullptr
I believe that we can remove the InitReadLocks code from LayerTransaction as that was added to
prevent file descriptor limits in IPDL messages and is no longer needed with this change. But
that is a non-essential change and this patch is already big enough.
MozReview-Commit-ID: DzHujrOQejH
--HG--
extra : rebase_source : 3bdd7c9bc8edfdc386faad8a9e59ad7dc18ed91d
We can easily populate the mId with the correct layers id, which is the
root layer tree id from the CompositorBridgeParent. This eliminates a
bunch of special-case handling.
MozReview-Commit-ID: FEkboAGEhYO
--HG--
extra : rebase_source : 01e73d516e5742d586cbf6d8b6bc5c9f7d64f141
Kartikaya Gupta
Noemi Erli
Alex Gaynor
Andrew Osmond
sotaro
Ryan VanderMeulen
Emilio Cobos Álvarez
Andreea Pavel
Ryan Hunt
Kearwood Gilbert
Lee Salzman
Nicolas Silva
arthur.iakab
Kearwood Gilbert
Nicholas Nethercote
Jeff Muizelaar
Zhang Junzhi
Narcis Beleuzu
Jeff Gilbert
Robert Longson