This was spot-tested by taking the
layout/reftests/border-radius-clipping-1.html testcase, removing the
border, and fiddling with the border-radius values. Without this patch,
the div always appears with rectangular corners but with this patch the
border-radius value is respected correctly.
MozReview-Commit-ID: 1wBFnJnYCwC
--HG--
extra : rebase_source : 542f814af9369fe712af76fc2a8c78de26c6227f
This was spot-tested by taking the
layout/reftests/border-radius-clipping-1.html testcase, removing the
border, and fiddling with the border-radius values. Without this patch,
the div always appears with rectangular corners but with this patch the
border-radius value is respected correctly.
MozReview-Commit-ID: Cu1K3rLjm0V
--HG--
extra : rebase_source : b5994faceb9dd7e52222714bdbc5b06886d26415
The test helper_touch_action_regions.html uses nsDOMWindowUtils to synthesize native input events and creates some runnables to trigger the test. It expects the runnables which synthesize native input events are processed first, then the runnables to continue the test, and finally the input events are forwarded from chrome process to content process. Enabling event prioritization may change the execution order.
Wraps those runnables to synthesize native input events as priority=input and dispatches those runnables to continue the test with priority=input to make sure the execution order is as expected.
MozReview-Commit-ID: 8hkaB1FRW9T
With DXVA2 hardware-video-decoding, the RendererOGL should have a
synchronization mechanism to prevent the flickering of video texture.
Create a SyncObject in RendererOGL to do the texture synchronization.
The WebRenderAPI also exposes the RendererOGL's SyncHandle to
WebRenderBridgeParent. Then, the WebRenderBridgeParent could pass this SyncHandle
to the video decoding module for texture synchronization.
MozReview-Commit-ID: toQ2mO5fzG
From bug 1163440, there is an additional AcquireSync() call around the swapChain::Present(). Export the KeyedMutex from SyncObjectD3D11Host for this synchronization.
MozReview-Commit-ID: 8mPs4jKj67W
The MLGDeviceD3D11, CompositorD3D11 and TextureClient use the same synchronization mechanism.
Create the new SyncObjectClient/Host types for reusing code.
Add SyncObject.cpp/h and create two new data types: SyncObjectClient and SyncObjectHost.
The SyncObjectClient is used for the TextureClient synchronization at client side.
The SyncObjectHost is used for the TextureHost synchronization in renderers such
as MLGDeviceD3D11 and CompositorD3D11.
MozReview-Commit-ID: 3l56WK1aZ15
Create the corresponding RenderTextureHost type and WR commands for DXGI texture type.
The DXGITextureHostD3D11 will use 1 or 2 image keys for non-nv12 and nv12 texture format.
The DXGIYCbCrTextureHostD3D11 is a special case. The WR uses ANGLE in windows platform,
but the ANGLE doesn't support A8 format directx texture directly. So, we use libyuv to
convert the DXGIYCbCrTextureHostD3D11 texture buffer into RGBA format buffer and use
WR::AddImage() for that image. This is a slow code path. We will refine this case later.
The whole RenderD3D11TextureHostOGL implementation is in the next patch.
MozReview-Commit-ID: F4mPCALj1OY
All WR texture related codes are move into GetWRImageKeys(), AddWRImage() and PushExternalImage().
Each texture type could generate its WR commands individually. So, this "mIsWrappingNativeHandle" flag is not used anymore.
MozReview-Commit-ID: 1TITkGRemAr
This commit adds the pref, 'apz.keyboard.passive-listeners', to allow web
content to have passive key event listeners and use keyboard APZ. When we are
allowing passive listeners, we need to dispatch the input to content and can
no longer consume the event. So we use mHandledByAPZ in nsXBLWindowKeyHandler
to determine whether we still need to do the default action, or whether it
has been done by APZ.
MozReview-Commit-ID: 2HAC6DjDyPZ
--HG--
extra : rebase_source : 77543ef3f28bdbb8ef77e984097ce75cdf333c82
This is for adding a pref that will allow web content to have key listeners
and use keyboard APZ, if they are marked passive. This commit also reworks
the function names and comments to make them more accurate.
MozReview-Commit-ID: LGDaVQOK1CS
--HG--
extra : rebase_source : a6bb4b7fff3488dea62b9114aa164814c74561a4
When WebRender creation is failed, WebRender is disabled in gecko. There is a case that WebRenderBridgeParents exist when WebRender is disabled. To handle this, gecko needs to rebuild all CompositorSessions.
There is also a problem related to gfxVars::UseWebRender on compositor thread. If e10s is enabled, but no-gpu process(default on linux and mac), gfxVars::UseWebRender change is soon notified by compositor thread tasks. If WebRender creation failure happens at 2nd WebRender creation, several WebRenderBridgeParents for 1st WebRender could exist. IPC messages from WebRenderLayerManager are normally async, then there is a chance that the WebRenderBridgeParents receive the messages after the gfxVars::UseWebRender change. Further the gfxVars::UseWebRender change in content process could be delayed than WebRenderBridgeParents, then content process does not have a way to stop sending PWebRenderBridge IPC until the change of gfxVars::UseWebRender is received. WebRenderBridgeParent related tasks handle the message, but some tasks are done based on gfxVars::UseWebRender. At this time, gfxVars::UseWebRender returned false on compositor thread, then it cause unexpected result for WebRenderBridgeParent and WebRender. To addres this inconsistent situation, WebRenderBridgeParent related tasks on compositor thread stop to use gfxVars::UseWebRender.
mLastCanvasDatas store used WebRenderCanvasData in last full
transaction. So that in next empty transaction, we can update canvas
content through mLastCanvasDatas.
MozReview-Commit-ID: 2H2m8R7Kzwf
This patch move common canvas interfaces out of layer. So I create a
base class CanvasRenderer which move interfaces from CanvasLayer.
CopyableCanvasRenderer from CopyableCanvasLayer, ClientCanvasRenderer
from ClientCanvasLayer and WebRenderCanvasRenderer from
WebRenderCanvasLayer. And finally, WebRenderCanvasRendererSync for the
non layers free mode and WebRenderCanvasRendererAsync for the layers
free mode.
Summary all changes in this patch.
* Move class CanvasLayer::Data to CanvasRenderer.h and rename it to
CanvasInitializeData. Because this class not only use by layer but also
* Move BasicCanvasLayer::UpdateSurface to
CopyableCanvasRenderer::ReadbackSurface.
* CanvasClient::Update now accepts ShareableCanvasRenderer as parameter.
not CanvasLayer.
use by layers-free mode. Move it out of layer's class makes more sense.
* Add InitializeCanvasRenderer in the canvas related classes to
initialize CanvasRenderer without involved layer.
* All canvas layer has function "CreateCanvasRendererInternal" that
initialize corresponding CanvasRenderer.
* Description of all CanvasRenderer classes:
** CanvasRenderer: Based classes.
** CopyableCanvasRenderer: Can readback canvas content to a
SourceSurface. Use by BasicCanvasLayer.
** ShareableCanvasRenderer: Provide IPC capabilities that allow sending
canvas content over IPC. This is pure virtual class because the IPC handling is
different in different LayerManager.
** ClientCanvasRenderer: Implement IPC handling for ClientLayerManager.
Use by ClientCanvasLayer.
** WebRenderCanvasRenderer: Implement IPC handling for
WebRenderLayerManager.
** WebRenderCanvasRendererSync: Use by WebRenderCanvasLayer.
** WebRenderCanvasRendererAsync: Use by layers-free mode in WebRender.
class diagram shows below:
+--------------+
|CanvasRenderer|
+-------+------+
^
|
+----------------------+
|CopyableCanvasRenderer|
+----------------------+
^
|
+-----------+-----------+
|ShareableCanvasRenderer|
+-----+-----------------+
^ ^
+-------------+ +-------+
| |
+--------------------+ +---------+-------------+
|ClientCanvasRenderer| |WebRenderCanvasRenderer|
+--------------------+ +--------+--+-----------+
^ ^
+-----------------------+ +----+
| |
+-------------+-------------+ +-------------+--------------+
|WebRenderCanvasRendererSync| |WebRenderCanvasRendererAsync|
+---------------------------+ +----------------------------+
MozReview-Commit-ID: 5hqQ19W169r
When empty transaction in layers free mode, we don't rebuild whole
display list. But the canvas content will be updated and send the
content to parent by CanvasClient. We need some mechanism just like
async video which can update the content without rebuild the dl. But
CanvasClient doesn't use ImageBridge at all. So I slightly modify
AddPipelineIdForAsyncCompositable to let it support the Compostiable
either store in ImageBridge or WebRenderBridgeParent.
MozReview-Commit-ID: 3mKv13Pgc2k
The notification is sent via GeckoContentController, PAPZCTreeManager if
necessary (to go from the GPU process to the parent process), and the
observer service.
Naturally, the notification is not sent in the case where it's browser.xml
that initiates the shutdown.
MozReview-Commit-ID: IAaSf4HiDF4
--HG--
extra : rebase_source : 80855ac7d3ae44c393dde96650b330cc737f69d6
The three main changes in this patch are:
(1) Move the code to emplace_back a new WebRenderLayerScrollData to
after the display list recursion. This is necessary so that when we
empty the temporary mLayerScrollData stack into the final mScrollData
structure things end up in the right order.
(2) Maintain a stack of ASRs as we recurse so that when we are building
a given WebRenderLayerScrollData, we don't add scroll metadatas that
are already present on its ancestors.
(3) Compute the number of descendants created for each layer scroll
data item and record it, so that we can properly reconstruct the
shape of the tree.
MozReview-Commit-ID: BSdX78AqBNZ
--HG--
extra : rebase_source : 0bb4133572d74fb756476e1c5954b17f114fe7d0
Instead of the WebRenderLayerScrollData code knowing about all the
different display item types, it makes more sense to move this logic
into the display items.
In addition to avoiding dis-encapsulating the data from nsDisplayItem subclasses,
this makes it easier to handle two specific scenarios:
(1) the case where an nsDisplayItem A subclasses another nsDisplayItem B, but A
and B have different types returned by GetType(). Previously A and B would have
to be handled explicitly in the WebRenderLayerScrollData switch statements,
which doesn't scale well if new types are added. With the new approach the
virtual function is shared down from A to B and so takes care of it. This is
particularly relevant for types like nsDisplayOwnLayer which have a number of
subclasses.
(2) the case where a display item *might* have APZ-relevant information.
In this case the type of the item alone is not sufficient to determine
if we need to create a new WebRenderLayerScrollData for it. Instead, we
need to access specific state inside the display item. This is now
handled by the UpdateScrollData function returning true when passed
nullptr arguments, and replaces the switch statement in
WebRenderLayerManager that updated forceNewLayerData.
MozReview-Commit-ID: FlfHlgSccSn
--HG--
extra : rebase_source : d1fe841724cc6020433aea31ffb5214d8a44d0a9
The messages are routed through nsITabParent, nsIWidget, and IAPZCTreeManager
(the latter possibly remoted via PAPZCTreeManager if out-of-process compositing
is used).
MozReview-Commit-ID: 1zXzLa1fqpG
--HG--
extra : rebase_source : c482816ecbaec0a889d817851ee15be186b2a49c
This involves adding a new type of AsyncPanZoomAnimation, a new APZC state,
and methods to start and stop autoscrolling.
MozReview-Commit-ID: BEYPJIR30Lw
--HG--
extra : rebase_source : 81a96fd73348853f9e1a94a9f72f7de0073cc66f
We should do SchedulePaint in nsImageFrame for layers-free mode and set
invalid flag to make sure the image will be repainted.
MozReview-Commit-ID: 2lXElZ151Qa
--HG--
extra : rebase_source : 56045f66f3b36afe8a6327b841d80073f1d038cb
We have a minimum requirement of VS 2015 for Windows builds, which supports
the z length modifier for format specifiers. So we don't need SizePrintfMacros.h
any more, and can just use %zu and friends directly everywhere.
MozReview-Commit-ID: 6s78RvPFMzv
--HG--
extra : rebase_source : 009ea39eb4dac1c927aa03e4f97d8ab673de8a0e
This adds handling for nsDisplayRemote frames, so that we create a
WebRenderLayerScrollData item for each nsDisplayRemote frame that we
encounter. This is the equivalent of a "ref layer" in a normal layer
tree, and allows the APZ side to glue together the scroll data from
different processes into a full tree.
MozReview-Commit-ID: 3lgsqtCKQya
--HG--
extra : rebase_source : eb93be1ef415349e00c09d7274d49fcf7992d197
The semantics of the WebRenderScrollData structure is that the per-layer
structures form a tree with a single root node. When we build the data
structure from the display list, we are generating (for now) a flat
list. Therefore we need to synthesize a root node in order to make stuff
work as intended.
MozReview-Commit-ID: IDXyziBO7pk
--HG--
extra : rebase_source : 99486a4c5b5e9938c4b7bbaa3f710d25e73d4401
Until now WebRenderScrollData was only used with "layers" WR
transactions, but we want to use it with layers-free transactions as
well. As such, we need to allow collecting information from display items
instead of layers. This restructures the code a little bit to allow
that. This patch should not have any functional effect on the "layers"
codepath, but on the "layers-free" codepath it is now actually
populating some rudimentary data into the WebRenderScrollData before
sending it across. This will be fleshed out in future patches.
MozReview-Commit-ID: BROqpsHPRND
--HG--
extra : rebase_source : 8510c52895e6be5cb546b42b02d56ec067de0623
This fixes a regression with apz.frame_delay.enabled=true introduced in
bug 1375949.
MozReview-Commit-ID: AIcGA7c2Co0
--HG--
extra : rebase_source : b118a97674cadef1359e7658539e4e0e9cb785b8
Bug 1365859 introduced a dependency on the Visual Studio binary 'fxc'
to generate Shader bytecode. This was unavailable when compiling for
Windows on Linux as part of a MinGW build.
This commit adds a configure check for fxc, and also searches for
fxc2, which was written (https://github.com/tomrittervg/fxc2) to be
a tiny application that wraps D3DCompileFromFile and can produce
similar (but not exactly the same) output as fxc.
fxc2 is compiled using MinGW for Windows, and runs under wine, so
we need to check for wine also.
Finally, fxc outputs some include information fxc2 doesn't, so
we will just change that assert to not take effect.
MozReview-Commit-ID: 8LVxuODi6cV
--HG--
extra : rebase_source : 9116d266663284d6594e34aa53bd37eae01ba67f
The pending transforms must have been computed using the older scroll offset
values, which means that updating the scroll offsets without recomputing the
transforms will make them wrong. If we do an empty transaction for the scroll
offset updates, the transforms will not get computed. This patch catches this
scenario and schedules a full paint instead of the empty transaction instead.
The case where the scroll offset is modified *before* the transform is already
handled by code in nsIFrame::TryUpdateTransformOnly.
MozReview-Commit-ID: I5s5J7BS1ru
--HG--
extra : rebase_source : 63fec656440c8bee322f069a4466a311ebcd0f7d
CompositorManagerChild::mCanSend is cleared in ActorDestroy but that
often comes in too late and after ContentChild::RecvReinitRendering
which reinitializes the singleton. For now, just remove the assert so
that we no longer trigger false positives in the content process after
the GPU process crashes.
This commit changes async keyboard scrolling to be enabled only if the content to
scroll is from a selection. This works around the problem of detecting whether
an arbitrary element has key listeners that should prevent async key scrolling,
because when they have the focus we will have disabled async key scrolling.
MozReview-Commit-ID: 6HhSuGZNsMX
--HG--
extra : rebase_source : 98a6449dd1e913136ca66532a67df8e0bb717e52
This also updates the WebRenderScrollDataWrapper function as it is meant
to be semantically equivalent to the LayerMetricsWrapper one, which
allows removal of a flag propagation.
MozReview-Commit-ID: 9DBx4qbhq5A
--HG--
extra : rebase_source : 3201d8a4bb7192ecdbe95983b605ac53b1a28c50
The test helper_touch_action_regions.html uses nsDOMWindowUtils to synthesize native input events and creates some runnables to trigger the test. It expects the runnables which synthesize native input events are processed first, then the runnables to continue the test, and finally the input events are forwarded from chrome process to content process. Enabling event prioritization may change the execution order.
Wraps those runnables to synthesize native input events as priority=input and dispatches those runnables to continue the test with priority=input to make sure the execution order is as expected.
MozReview-Commit-ID: 8hkaB1FRW9T
Ideally, we definitely want APZ in remote popup browsers for the sake of
responsiveness. However, there are currently some serious painting and
checkerboarding issues that make APZ popups unsuitable for release
populations.
Once these issues are addressed, we should enable the preference by default.
But given the relative lack of testing, and the issues we've seen so far, we
should keep the preference so that we can disable it with a hotfix if further
issues arise.
MozReview-Commit-ID: GOZRdsmLNZR
--HG--
extra : rebase_source : ce0f2ca029d951a9c65ec1482e065b6695793133
This patch allows us to decide whether to use blob images depending on a MustPaintOnContentSide flag exposed by each display item. If any of the display item assigned to a given painted layer data have this flag, then the painted layer data is marked as preferring content side painting and the webrender layer manager uses this information to decide whether to create a regular content layer or serialize the drawing commands with blob image. This is useful for items that must be painted on the content side such as scroll bars, checkboxes, buttons, etc. Using blob images for these makes us first paint the widget on the content side, then serialize the painted pixels and blit the content again in the blob image which has a lot more overhead than painting the content into a layer and sharing it with webrender directly.
Previously, we submitted polygons as a list of triangles, duplicating
some ancillary data with each vertex. As we move away from constant
buffers for some of this ancillary data, it will bloat the size of each
vertex. To avoid this, we will now instance over a unit triangle
instead. Each instance contains three triangle coordinates and ancillary
data can be shared between them. The target vertex is computed similarly
to how we handle rects in the unit quad shaders.
The patch removes CompositorBridgeParentBase::GetAnimationStorage and CrossProcessCompositorBridgeParent::GetAnimationStorage, and remove the "aId" parameter to CompositorBridgeParent::GetAnimationStorage, since it's only ever called with "0" as the argument.
The test was assuming that processing an input event that causes async
scrolling will result in the async scroll being reflected on the next
composite. With the changes in this bug, that is no longer a valid assumption.
MozReview-Commit-ID: HAB3xnmF3vo
--HG--
extra : rebase_source : 86eca7c9f030a2bf4be87d8aa632a97584722191
With this in place, scroll-linked effects will remain in sync with async
scrolling if they can be processed and painted within the frame budget.
This change is currently behind a pref that's off by default.
MozReview-Commit-ID: 6GEJTKZh6ON
--HG--
extra : rebase_source : 534bf15ef1c5ca26e1dc0d7eb298063b80aa9dd3
The AsyncTransformConsumer enumeration captures the distinction between
the two main categories of consumers of async transforms: those using
it for hit-testing and related purposes, and those using it for
compositing.
MozReview-Commit-ID: 59CICcnPvY6
--HG--
extra : rebase_source : ba505e6b2b6f42592660074939a6d24aab7f73ff
Bug 1365859 introduced a dependency on the Visual Studio binary 'fxc'
to generate Shader bytecode. This was unavailable when compiling for
Windows on Linux as part of a MinGW build.
This commit adds a configure check for fxc, and also searches for
fxc2, which was written (https://github.com/tomrittervg/fxc2) to be
a tiny application that wraps D3DCompileFromFile and can produce
similar (but not exactly the same) output as fxc.
fxc2 is compiled using MinGW for Windows, and runs under wine, so
we need to check for wine also.
Finally, fxc outputs some include information fxc2 doesn't, so
we will just change that assert to not take effect.
MozReview-Commit-ID: 8LVxuODi6cV
--HG--
extra : rebase_source : 39acca112f4cd9e6c39f7e47e7c55b13e7606824
For RTL scrollframes the scrollable rect can extend into the negative-x coordinate
space as the user can scroll leftwards from the "zero" position. The code was
assuming a zero minimum scroll position in a couple of places which broke down
on RTL scrollframes.
MozReview-Commit-ID: 5FxELpafWSD
--HG--
extra : rebase_source : a3c7614528cf59a5c60f350fca84161c8586509f
One thing to note here is that the Scale function on gfxRect has a
different implementation than that in gfx::Rect which is replacing it.
The former just scales the width/height directly whereas the latter
scales the XMost/YMost and recomputes the width/height.
MozReview-Commit-ID: 5FImdIaNfC3
--HG--
extra : rebase_source : 98662d2a52ff9652ec60b066641a07c6d5ee8e08
Most of this patch is updating a few places that use gfxMatrix to use
the equivalent-but-differently-named functions on MatrixDouble:
- Translate/Rotate/Scale get turned into PreTranslate/PreRotate/PreScale
- Transform(Point) gets turned into TransformPoint(Point)
- gfxMatrix::TransformBounds(gfxRect) gets turned into
gfxRect::TransformBoundsBy(gfxMatrix).
- gfxMatrix::Transform(gfxRect) gets turned into
gfxRect::TransformBy(gfxMatrix).
The last two functions are added in this patch as convenience wrappers
to gfxRect instead of Matrix.h because we don't want Matrix.h to "know"
about gfxRect (to avoid adding gecko dependencies on Moz2D). Once we
turn gfxRect into a typedef for RectDouble these will be eliminated
anyway.
MozReview-Commit-ID: BnOjHzmOSKn
--HG--
extra : rebase_source : cf1692d1f0d44a4b05d684a66678739181a426d5
This extracts a BaseMatrix template of which Matrix is now a particular
specialization. The BaseMatrix allows us to reuse the same code for
floats and doubles, much like the other "base" classes (BasePoint,
BaseRect, etc.).
MozReview-Commit-ID: HO7bA83S9E0
--HG--
extra : rebase_source : dcd84d9a978cdea00bb54eb11eefcca9c6635901
Layers are retained between transaction and we store some data in the layers.
Thus, if we no longer use layers, we need find another storage to place
those data. I use frame's property to retain WebRenderUserData between
transaction.
MozReview-Commit-ID: Ku5VGBXa3w6
--HG--
extra : rebase_source : 636653f78d1d6c310726a1a2c944141dc691decc
This requires:
- Moving the constructors of ProfilerMarkerPayload and its subclasses into the
.h file so they are visible even when ProfilerMarkerPayload.cpp isn't
compiled.
- Similarly, using a macro to make StreamPayload() a crashing no-op when the
profiler isn't enabled. (It is never called in that case.)
--HG--
extra : rebase_source : 7aad2fdb1bd4e49782024dba6664e8f992771520
The patch fixes a problem on windows. Before the patch, there was a case that moved tab was not re-rendered. When WebRenderBridgeParent reveived obsolted transaction, DidComposite() was not returned to a client side. It stopped nsRefreshDriver to trigger a next transaction.
When the tab move happens, related non-root WebRenderBridgeParent is updated as to render to different webrender instance. webrender does not support of sharing resources and keys yet. Then when the tab move happens, the patch just removes all keys and resources that belongs to previous webrender. Ideally all resources that belong to WebRenderBridgeParent should be reallocated in an update webrender. But the patch does not do it, instead it just request WebRenderBridgeChild to re-allocate all resources again for simplicity. Performance improvement will happen in a future patch.
This patch support only tab move that uses only raw data external images. Support of native texture external images will happen in a future patch.
The patch fixes a problem on windows. Before the patch, there was a case that moved tab was not re-rendered. When WebRenderBridgeParent reveived obsolted transaction, DidComposite() was not returned to a client side. It stopped nsRefreshDriver to trigger a next transaction.
When the tab move happens, related non-root WebRenderBridgeParent is updated as to render to different webrender instance. webrender does not support of sharing resources and keys yet. Then when the tab move happens, the patch just removes all keys and resources that belongs to previous webrender. Ideally all resources that belong to WebRenderBridgeParent should be reallocated in an update webrender. But the patch does not do it, instead it just request WebRenderBridgeChild to re-allocate all resources again for simplicity. Performance improvement will happen in a future patch.
This patch support only tab move that uses only raw data external images. Support of native texture external images will happen in a future patch.
The Init()/Shutdown() would be run on the main thread, AcquireTexture() would be
on media thread and Fill() would be on compostitor thread.
Add assertion to make sure the call order, since we don't want to call Fill()
or AcquireTexture() after shutdown.
MozReview-Commit-ID: 3Gydr7b4Raq
--HG--
extra : rebase_source : a81f7a58c94b2fc75bba500a6a2d087e05b520cd
The pool would be refilled when the compositor starts rendering the frame.
However, if we consume lots of textures but doesn't render any frame, then the
pool would always empty and no one can get new texture id.
One case is that when we release decoders too early before rendering the first
frame, the pool won't be refilled, and it causes all media threads are blocked.
Now we would refill the pool if the textures number is lower than the specific
threshold.
MozReview-Commit-ID: CYBLYi9hFD9
--HG--
extra : rebase_source : 309338a4cf2283ed93afcc4af2cc1cf5e925661d
Most of the changes in this patch are just using the explicit
constructor from gfx::IntSize to gfx::Size, since gfxSize did
that implicitly but gfx::Size doesn't.
MozReview-Commit-ID: CzikGjHEXje
--HG--
extra : rebase_source : 9d19977f2a774d9a2a653db923553a6c2e06f82a
This allows testing code control over the animation steps running over in the
compositor, which is needed for the OMTA mochitests.
MozReview-Commit-ID: CXJcieSEoRl
--HG--
extra : rebase_source : ad73196ac835e7aae0003befa8c71e81a9019dd2
This will make these functions usable from WebRenderBridgeParent, which has a
layers id but doesn't have a LayerTransactionParent.
MozReview-Commit-ID: FvxGPdLeUWe
--HG--
extra : rebase_source : eaed5dedeccda41068cade3d5b4527d0f047eed9
This is a better name for the header that matches its main class.
MozReview-Commit-ID: KSt9LVT3yRR
--HG--
rename : gfx/layers/apz/src/Keyboard.cpp => gfx/layers/apz/src/KeyboardMap.cpp
rename : gfx/layers/apz/src/Keyboard.h => gfx/layers/apz/src/KeyboardMap.h
extra : rebase_source : ec4c9ec5afa8479dc4cd3e987fc3293f047beb9e
extra : histedit_source : caa3a11043fc1ccdff3d7853eda69a0a3dfff99e
When keyboard apz is disabled, we don't need to calculate focus targets and
we don't need to update focus state. It should be harmless even if it's done,
but I think it's good to not add something on this critical path that doesn't
do anything.
This commit also disable keyboard map generation in this case too for similar
reasoning. This has the side effect that you can't turn on keyboard apz without
doing a restart.
MozReview-Commit-ID: LxmofT2g7qs
--HG--
extra : rebase_source : 719d29efd80498b824fee03a5be1c1fd05c83074
extra : histedit_source : 7ad71a19782fc6dd203207afbdc7a73a936b3e04
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
David Anderson
Stone Shih
vincentliu
Ethan Lin
Mason Chang
Kartikaya Gupta
Sebastian Hengst
JerryShih
sotaro
Ryan Hunt
Morris Tseng
Wes Kocher
Randall Barker
Botond Ballo
Phil Ringnalda
Nicolas Silva
Carsten "Tomcat" Book
Ehsan Akhgari
Kearwood Gilbert
Milan Sreckovic
Bevis Tseng
Nathan Froyd
Samael Wang
Tom Ritter
Ryan VanderMeulen
Kevin Chen
Sylvestre Ledru
peter chang
Andrew Osmond
Kris Maglione
Nicholas Nethercote
Mats Palmgren
David Anderson
Alastor Wu
Andrew McCreight
Michael Layzell