This commit ties it all together by dispatching keyboard actions to scroll targets
in response to keyboard inputs when we have current and valid focus state.
MozReview-Commit-ID: G7rZiS3FH5e
--HG--
extra : rebase_source : 10129d417fe8ef576cac5bda3157dd8f65b5843a
extra : histedit_source : be651a33f787f68bc764988ddc073d346e854491
This commit adds code for keyboard scroll animations and computing the delta
needed for a keyboard scroll action. Keyboard scrolling behavior is more complex
with scroll snapping, so we don't support async keyboard scrolling when we have
scroll snap points.
MozReview-Commit-ID: 97CpprCBp2A
--HG--
extra : rebase_source : 154b2c6b5a6c587fca011ab885c8d46ba6b4d80a
extra : histedit_source : 87ba53fe89069a47751d9ce25fc344011fb0f4de
Focus can change at any moment in a document. This causes non-determinism and
correctness problems for doing keyboard apz scrolling. To get around this, we
will maintain deterministic behavior for focus changes initiated by input events
and see if we can get away with more non-determinism for things like `setTimeout`
In order to do this, we disable async keyboard scrolling when an input event is
processed that could have a event listener. We then attach a sequence number to
that input event and dispatch it to content. In content, we record the highest
sequence number that we have processed from an event, and send that on each focus
update. Using this, we can determine in APZ if we have a current focus target or
if we are still waiting for an input event to be processed and focus to be
reconfirmed.
MozReview-Commit-ID: CWcu8YEFQz4
--HG--
extra : rebase_source : 8c54a619bd4f5ee892f0cc8768a10f3e1e4e0b59
extra : histedit_source : 601ca293a028787883841adc6b40e62c0cc829e5
This commit modifies PresShell and nsDisplayList to send a FocusTarget update on
every layer transaction. Ideally we would like to send updates as often as possible,
but this seems like it works well. This can be iterated on later, if necessary.
MozReview-Commit-ID: 8PFqIOhzH77
--HG--
extra : rebase_source : 1e2c3b5620f5d7e6e789848da57b2486c3d74f14
This commit updates FocusTarget to disable itself if the focused element is editable,
or is a part of an editable document. This is needed because we cannot do async
scrolling when this is the case.
MozReview-Commit-ID: Fl7W3967djG
--HG--
extra : rebase_source : f376dec47965ade11055e10d68311fa9566aca9f
This commit updates FocusTarget to collect whether there are key listeners
on the event target chain for the focused element. This is needed because we
cannot do async scrolling when this is the case.
MozReview-Commit-ID: FhSyF6ffZ4
--HG--
extra : rebase_source : 3e7e8e88ddda1a6b9e8542c131fdbb37e578d7e1
This commit begins the work needed for tracking focus by creating two new classes,
FocusTarget and FocusState. FocusState is created and used by APZCTreeManager to
track the global focus information, while FocusTarget is created per layer tree and
sent to APZ with local focus information. Between the two we are able to figure out
what the correct scrollable layer is to use in response to a keyboard scroll.
See the comment in `FocusState.h` for more details on the architecture and things
needed in future patches to complete this.
MozReview-Commit-ID: F75VZv3i9U2
--HG--
extra : rebase_source : 3d04bced8e13a9884f0c1b320bad8ba2205d7011
This commit makes it so we initialize, send, and store a KeyboardMap for every
APZCTreeManager for later keyboard event processing.
This is a naive approach so it may be worth improving.
MozReview-Commit-ID: CYTbLL3wRlC
--HG--
extra : rebase_source : 016b80a2a209d4fb5b92bc3adb95bd2dbb4399e0
The XBL bindings used for scrolling are managed by a nsXBLWindowKeyHandler. This
class loads the handlers and has logic for searching through them to match a
keyboard event. This commit adds a KeyboardMap class for storing KeyboardShortcuts
and for mirroring the search logic of nsXBLWindowKeyHandler.
MozReview-Commit-ID: 5BmFBilKTJy
--HG--
extra : rebase_source : 96cd0f5808ba6c4926e9da368ab3780b1d9d1449
Keyboard scrolling works by first dispatching a key event to the focused element
of the page. It is then caught by a XBL binding put on the chrome event handler of
every window. The XBL binding searches through all of its handlers to find one
that can handle the keyboard event. The matching binding has a command string
which is dispatched to the nsGlobalWindowCommands which dispatches to PresShell
which does the actual scrolling.
To do this asynchronously, we need a representation of the XBL handlers that can
be applied to a KeyboardInput to get a KeyboardAction.
This commit adds KeyboardShortcut for this purpose. KeyboardShortcut is designed
to be compatible with nsXBLPrototypeHandler and to only handle the specific cases
we care about for keyboard scrolling. If a XBL handler runs javascript or does
anything else we cannot handle in an OMT situation, then we create a
dispatch-to-content KeyboardShortcut.
MozReview-Commit-ID: 1qzywS3QHVp
--HG--
extra : rebase_source : 8ea4f85c02d04ce5e0fa6e430c44ac920269dd9f
The different types of keyboard scrolls are represented as command strings that
are dispatched to nsGlobalWindowCommands. This commit adds a class to represent
these command strings, along with a function to find the keyboard scroll action
corresponding to a command string.
MozReview-Commit-ID: 20vvYdzlYYT
--HG--
extra : rebase_source : 8a965429f57534ac65da597cbb05a08284f7eaeb
Once the |aPayload| argument to profile_add_marker() became a UniquePtr the
default value of nullptr caused compilation difficulties that could only be
fixed by #including ProfilerMarkerPayload.h into lots of additional places
(because the UniquePtr<T> instantiation required the T to be fully defined). To
get around this I just split profile_add_marker() into two functions, one with
1 argument and one with 2 arguments.
The patch also removes the definition of PROFILER_MARKER_PAYLOAD in the case
where MOZ_GECKO_PROFILER isn't defined. A comment explains why.
- Validate GetSharedResourceView in VRDisplayOculus::SubmitFrame and VRDisplayPuppet::SubmitFrame
- Correct size of frameIndex to be "long long" rather than "int" for
ovr_GetPredictedDisplayTime
- Updated to Oculus 1.15.0 SDK
- Now sending absolute timestamp of the predicted frame time
to ovr_GetTrackingState rather than a delta
MozReview-Commit-ID: GLSkqwae7Jp
--HG--
extra : rebase_source : 80a051c4af9e2241fe971fc2763015b5f3d18f7c
This bug handles abnormal client shut down case and Tab move between different windows.
Abnormal client shut down case, WebRenderBridgeParent does not receive IPC messages that are sent during WebRenderLayerManager and WebRenderBridgeChild destruction. In this case, webrender keys except keys of external images are not removed from webrender. Abnormal shut down could happen when content process was crashed or content process was killed by ContentParent if shutdown takes too long time.
In the tab move case, the WebRenderBridgeParent will need to be re-bound to a different CompositorBridgeParent and webrender, and so will need to clear all its related keys from the old webrender. This will happen in a future patch.
The async images codepath is a bit different in that it pushes an iframe
item to the WR display list and updates it asynchronously. However in
this case it still makes sense to push the layer's local clip
outside the iframe, and just populate the iframe with the image and not
worry about clips inside the iframe. As mentioned in part 1 of this
patchset, this will be needed to properly handle async scrolling.
This patch makes the necessary changes to push the clip outside the
iframe and simplifies what happens in WebRenderCompositableHolder to
generate the display list for the iframe itself.
MozReview-Commit-ID: DeZElH4p4rc
--HG--
extra : rebase_source : 3f3458a6c2607b8290dc2174a248f3d7bd33a3a9
Since part 1 of this patch set pushed the layer's local clip as part of
the code in ScrollingLayersHelper, it is no longer needed in the
WebRenderDisplayItemLayer (it is effectively duplicated).
MozReview-Commit-ID: F2HFsx3XI9M
--HG--
extra : rebase_source : 5dfcecb649376d6958760e4e95cd025d01f3124c
This ensures that for layers with both transforms and mask layers, the
mask layer is properly positioned outside of the transform and relative
to the proper stacking context.
MozReview-Commit-ID: 79yvhxQCykW
--HG--
extra : rebase_source : 353a7dcc59fb2df0ff2379909a08986ec176ac50
For various reasons, we want to be pushing the layer's local clip rect
outside of the stacking context rather than inside it. Not only is this
more correct with respect to the semantics of the layer tree, we also
need it in order to properly handle fixed-positioning of layers with
async scrolling.
This patch does the bulk of the work to make this happen. Most of the code
in the individual layer classes to process the layer's local clip rect
is removed, and instead a function in ScrollingLayersHelper is added to
deal with it. There are a couple of places that individual layer classes
still handle this but those will be removed in future patches. Note that
the individual layer classes still need to provide a clip rect of some
sort in order to push their display items, and now they simply use their
visible region bounds for this purpose.
MozReview-Commit-ID: IBmfUdJwYx1
--HG--
extra : rebase_source : 3f48a707f35a398711813d859af1e7184f19fd40
In windows platform, gecko will use GPUVideoTextureHost type for remote video decoding.
Implement the WR related functions for this type.
MozReview-Commit-ID: KSpndcApK3H
This bug handles abnormal client shut down case and Tab move between different windows.
Abnormal client shut down case, WebRenderBridgeParent does not receive IPC messages that are sent during WebRenderLayerManager and WebRenderBridgeChild destruction. In this case, animations under the WebRenderBridgeChild are not removed from CompositorAnimationStorage. Abnormal shut down could happen when content process was crashed or content process was killed by ContentParent if shutdown takes too long time.
In the tab move case, the WebRenderBridgeParent will need to be re-bound to a different CompositorBridgeParent and CompositorAnimationStorage, and so will need to clear all its active animations from the old CompositorAnimationStorage and add animations into the new CompositorAnimationStorage. This will happen in a future patch.
Get the latest gl.xml, egl.xml, wgl.xml and glx.xml.
Then, execute the |GLParseRegistryXML.py|. Please check the details in |GLParseRegistryXML.py|.
The ANGLE_stream_producer_d3d_texture_nv12 and ANGLE_keyed_mutex extension are not exist in egl.xml,
so add the "LOCAL_EGL_DXGI_KEYED_MUTEX_ANGLE" and "LOCAL_EGL_D3D_TEXTURE_SUBRESOURCE_ID_ANGLE" manually in GLDefs.h.
egl:
2e6e7ff7bf
gl, glx and wgl:
23a3a95673
This message intends to print out a string but was inadvertantly converting
the string pointer to a hex value. Adding an implicit conversion of char16ptr_t
to |wchar*| breaks this, so we just update the code to actually convert and
print the string instead.
MozReview-Commit-ID: 90luEnoysX3
In addition to update webrender/ and webrender_traits/, this updates
the webrender_bindings dependency on euclid to euclid-0.14.4. It also
updates some webrender_bindings code for this dependency update, and
for the BlobImageRenderer API change in WR cset 36a9117.
MozReview-Commit-ID: JlmTHrFdfUM
--HG--
rename : third_party/rust/euclid/src/matrix2d.rs => third_party/rust/euclid-0.13.0/src/matrix2d.rs
rename : third_party/rust/euclid/src/matrix4d.rs => third_party/rust/euclid-0.13.0/src/matrix4d.rs
This keeps around mFinalDT but mostly doesn't use it (except for when creating
a PathBuilder). All playback is ripped out and we'll no longer hold references
to things to mFinalDT::GraidentStops or SourceSurfaces etc.
This makes sure that we use a DrawTargetRecording when we're recording.
Previously we were trying to draw a SourceSurfaceRecording into an
Offscreen DrawTarget which in this case was a DrawTargetSkia which
doesn't support SourceSurfaceRecordings. This changes avoids the
DrawTargetSkia.
The new clip from bug 1364007 can cause us to clip to a rectangle that's not
aligned to device pixels. With the current rect inflation, we didn't notice,
but if we want to remove the inflation then we need to make sure to round out
the rect that we clip to.
MozReview-Commit-ID: BO9zds8fiKI
--HG--
extra : rebase_source : f71f283ef73cf58dbc2cc05d06ea9bc864fd5084
This helps keep us from accumulating all of the recorders.
The basic idea is to track weak references to the SourceSurfaces and Fonts that
we add UserData to in DrawEventRecorderPrivate and then clear these UserData's
when we're done recording.
This adds a RemoveAndDestroy helper to UserData to make this possible.
Due to the confusing precedence of reftest manifest conditions,
we are running these tests when we shouldn't be.
MozReview-Commit-ID: 6RgI0NgWvay
--HG--
extra : rebase_source : 2e6a8113e1444bef52131ad9c119a31a7e855b7f
This implements at least enough fixed-positioning support to make the
reftest in layout/reftests/async-scrolling/bg-fixed-child.html pass.
That test implements a simple background-attachment:fixed which is
implemented in the layer tree with a combination of a scrolled clip and
a fixed-position layer. Previous patches in this patchset implemented
support for the scrolled clip, and this patch implements the
fixed-position layer support.
MozReview-Commit-ID: 1Al1YshhUL7
--HG--
extra : rebase_source : e50d5572264567acc03f1ecf220c57c7b5a85a4f
Tracking the active clips and scroll layers is helpful for implementing
fixed-position type stuff, because we will need to answer questions like
"what is the ancestor scroll layer of this other scroll layer that is
somewhere on the stack" and "what is the currently active stack of
non-scrolling clips". This patch also adds a couple of methods to
WebRenderAPI that answers questions like these.
MozReview-Commit-ID: 9bgOW3Z8Tbp
--HG--
extra : rebase_source : 382f1d476217739d9e023e05d8b3886f268c6b72
If the layer has a "scrolled clip", that clip scrolls with the content
of the layers (it moves if any of the scrollable frames defined by that
layer are scrolled).
MozReview-Commit-ID: 37hvXWO930f
--HG--
extra : rebase_source : 4150c3bb061d027b483e44418bec7f3b810a9ccc
Activate WebRender output for filters that introduce only one pixel
differences in tests. Since the filters spec does not seem to specify
how color values are rounded, this output should be spec compliant.
If we call UnregisterExternalImage() at non-render-thread and decrease the RenderTextureHost's ref-count to zero, the RenderTextureHost will be released in non-render-thread.
That will cause some problems if we use some thread-specific functions in ~RenderTextureHost().
This patch uses a message loop in UnregisterExternalImage() to resolve this problem.
MozReview-Commit-ID: CDazxGkE1cK
The RenderTextureHost might calls some thread-specific functions(e.g. OpenGL calls) in ~RenderTextureHost(). Add a checking here to prevent this problem.
MozReview-Commit-ID: 62QlavmXOig
WR supports the planar-ycbcr image format. We turn to use the planar-ycbcr image to get rid of the software-ycbcr-to-rgb color format conversion(using libyuv) in gecko.
The BufferTextureHost will use 3 image keys for SurfaceFormat::YUV format.
The RenderBufferTextureHost will also use 3 DataSourceSurfaces to represent the 3 channel data in planar-ycbcr format.
MozReview-Commit-ID: 3mMreSzKnMv
These 2 functions are used for WR.
The GetWRImageKeys() will return the proper image keys according to the textureHost format.
The PushExternalImage() will put all necessary WR commands into DisplayListBuilder for the textureHost rendering.
MozReview-Commit-ID: FwCDxwsCMMy
It's awful to put all combination of image key and WR command settings in the same place. Make the settings go back to textureHosts.
Each textureHost should implement GetWRImageKeys() and PushExternalImage() function.
MozReview-Commit-ID: 5Bmiuv5HgmX
Wherever possible, we exhaustively list all the possibilities instead of
having "default" branches. This way if new items are added to the enum
they won't silently end up in the "default" branch, but the compiler can
tell us that we skipped handling it.
Also wherever possible, the existing NS_WARNINGs were upgrade to
MOZ_ASSERTs or equivalent.
MozReview-Commit-ID: IVDiI0gjFtU
--HG--
extra : rebase_source : 93bac9678e44e2f42602e10d0c7eea26366bae37
The caller of RenderHighPrecision and RenderLowPrecision doesn't look at the
variable that it passes as the aInvalidRegion parameter after the call, so any
modifications that would have happened to this variable don't matter.
MozReview-Commit-ID: B9PaXjZkxv2
--HG--
extra : rebase_source : fb66ae3170a9891fbb5d4d90aebf78230b8f9ce0
This patch makes the bg-fixed-child-mask.html reftest pass by ensuring
the clips for the test case are all in the correct spots. See the
comments in the patch for a more detailed explanation.
MozReview-Commit-ID: 21MAHr0PJ9B
--HG--
extra : rebase_source : 649a539a9c9417784c1cd025e372eb7823844bec
This patch is not really needed, but it avoids accidental conversion
between FrameMetrics::ViewID (which represents a scrolling clip) and a
uint64_t id for a non-scrolling clip.
MozReview-Commit-ID: JriIfpECHe7
--HG--
extra : rebase_source : a7af8465c9c62a60856c190da64667439233f4b0
Each layer has a stack of scroll metadata objects, which represent the
set of scrollframes that got flattened into the layer. Effectively the
metadata objects provide the scroll information for the chain of
scrollframes containing that layer's content. Each of these scrollframes
may have a clip, and so we need to push those clips to WR. We need to
take care to insert these clips at the right point in the stack, so that
they are interleaved correctly with the PushScrollLayer calls that we
use to inform WR of the scrolling clips for the scrollframes. This patch
implements this behaviour.
MozReview-Commit-ID: HD3OO5TZHSr
--HG--
extra : rebase_source : 8c5c3b027f3fa6fca8394c57769845569387f32e
No functional changes. We'll want to reuse this code in a future patch.
MozReview-Commit-ID: LEuP38yXBHI
--HG--
extra : rebase_source : 11faa0123e987c255dd7495e4b704346ab2b714d
This patch makes the bg-fixed-child-mask.html reftest pass by ensuring
the clips for the test case are all in the correct spots. See the
comments in the patch for a more detailed explanation.
MozReview-Commit-ID: 5HHtsSkcsji
--HG--
extra : rebase_source : d5d52f33714407a0df41ca06a6a298bef3154c74
This patch is not really needed, but it avoids accidental conversion
between FrameMetrics::ViewID (which represents a scrolling clip) and a
uint64_t id for a non-scrolling clip.
MozReview-Commit-ID: BU7p4WNocXa
--HG--
extra : rebase_source : 0cf69ca0a7b716bd9ad5c3cef114a3b99ec00e1b
Each layer has a stack of scroll metadata objects, which represent the
set of scrollframes that got flattened into the layer. Effectively the
metadata objects provide the scroll information for the chain of
scrollframes containing that layer's content. Each of these scrollframes
may have a clip, and so we need to push those clips to WR. We need to
take care to insert these clips at the right point in the stack, so that
they are interleaved correctly with the PushScrollLayer calls that we
use to inform WR of the scrolling clips for the scrollframes. This patch
implements this behaviour.
MozReview-Commit-ID: BayxnZuqh4s
--HG--
extra : rebase_source : 94b8ab464c5648a2e87d94ed9d95ed5ff3f486a3
No functional changes. We'll want to reuse this code in a future patch.
MozReview-Commit-ID: 1nrMuS9n8A5
--HG--
extra : rebase_source : 75112a65645147c85643d4cd2cf253de3242825b
Now that, thanks to bug 1367577, we have the theme constants in an enum,
we can make these arrays smaller rather than assuming that the constants
might use any valid uint8_t value.
MozReview-Commit-ID: A6GjTarVurc
If we call UnregisterExternalImage() at non-render-thread and decrease the RenderTextureHost's ref-count to zero, the RenderTextureHost will be released in non-render-thread.
That will cause some problems if we use some thread-specific functions in ~RenderTextureHost().
This patch uses a message loop in UnregisterExternalImage() to resolve this problem.
MozReview-Commit-ID: CDazxGkE1cK
The RenderTextureHost might calls some thread-specific functions(e.g. OpenGL calls) in ~RenderTextureHost(). Add a checking here to prevent this problem.
MozReview-Commit-ID: 62QlavmXOig
WR supports the planar-ycbcr image format. We turn to use the planar-ycbcr image to get rid of the software-ycbcr-to-rgb color format conversion(using libyuv) in gecko.
The BufferTextureHost will use 3 image keys for SurfaceFormat::YUV format.
The RenderBufferTextureHost will also use 3 DataSourceSurfaces to represent the 3 channel data in planar-ycbcr format.
MozReview-Commit-ID: 3mMreSzKnMv
These 2 functions are used for WR.
The GetWRImageKeys() will return the proper image keys according to the textureHost format.
The PushExternalImage() will put all necessary WR commands into DisplayListBuilder for the textureHost rendering.
MozReview-Commit-ID: FwCDxwsCMMy
It's awful to put all combination of image key and WR command settings in the same place. Make the settings go back to textureHosts.
Each textureHost should implement GetWRImageKeys() and PushExternalImage() function.
MozReview-Commit-ID: 5Bmiuv5HgmX
When gecko go through the reusing case, the aUseExternalImage isn't set to the correct value. It is always false here.
Then, gecko will use the non-external-image code path later. Add a new data member "mUseExternalImage" to save the previous status.
MozReview-Commit-ID: KvzgIzYXNAB
This mostly just copies the functional parts of the APZTestData code from
ClientLayerManager into WebRenderLayerManager, and propagates the paint sequence
number over to the compositor using the existing WebRenderScrollData machinery.
MozReview-Commit-ID: LHupFpqtWTX
This is fairly straightforward plumbing. The webrender equivalent of PLayerTransaction
is PWebRenderBridge and we can use that to get the compositor-side APZTestData.
MozReview-Commit-ID: Bn8WjKW5GoI