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
No functional changes intended in this patch. It merely simplifies the
additional patch that we'll need to update gecko past WR cset 0bf6655,
and saves some potential manual rebasing work.
MozReview-Commit-ID: Km8dBotP3NQ
--HG--
extra : rebase_source : 77c34ec1cbbc1c0fe4d1971feb131d30c97f0d66
This patch makes the following changes to the macros.
- Removes PROFILER_LABEL_FUNC. It's only suitable for use in functions outside
classes, due to PROFILER_FUNCTION_NAME not getting class names, and it was
mostly misused.
- Removes PROFILER_FUNCTION_NAME. It's no longer used, and __func__ is
universally available now anyway.
- Combines the first two string literal arguments of PROFILER_LABEL and
PROFILER_LABEL_DYNAMIC into a single argument. There was no good reason for
them to be separate, and it forced a '::' in the label, which isn't always
appropriate. Also, the meaning of the "name_space" argument was interpreted
in an interesting variety of ways.
- Adds an "AUTO_" prefix to PROFILER_LABEL and PROFILER_LABEL_DYNAMIC, to make
it clearer they construct RAII objects rather than just being function calls.
(I myself have screwed up the scoping because of this in the past.)
- Fills in the 'js::ProfileEntry::Category::' qualifier within the macro, so
the caller doesn't need to. This makes a *lot* more of the uses fit onto a
single line.
The patch also makes the following changes to the macro uses (beyond those
required by the changes described above).
- Fixes a bunch of labels that had gotten out of sync with the name of the
class and/or function that encloses them.
- Removes a useless PROFILER_LABEL use within a trivial scope in
EventStateManager::DispatchMouseOrPointerEvent(). It clearly wasn't serving
any useful purpose. It also serves as extra evidence that the AUTO_ prefix is
a good idea.
- Tweaks DecodePool::SyncRunIf{Preferred,Possible} so that the labelling is
done within them, instead of at their callsites, because that's a more
standard way of doing things.
--HG--
extra : rebase_source : 318d1bc6fc1425a94aacbf489dd46e4f83211de4
PROFILER_MARKER is now just a trivial wrapper for profiler_add_marker(). This
patch removes it.
--HG--
extra : rebase_source : 9858f34763bb343757896a91ab7ad8bd8e56b076
gfx/layers/AsyncCanvasRenderer.cpp:62:10 [-Wunused-member-function] unused member function 'Revoke'
gfx/layers/AsyncCanvasRenderer.cpp:97:10 [-Wunused-member-function] unused member function 'Revoke'
MozReview-Commit-ID: 11CjGtiXIqv
--HG--
extra : source : a1bc00d769d882d1bd8bbc8a34b48751e488fcb9
extra : intermediate-source : 8f7a070ec05778d6a4f42417772bdd552a433ccc
extra : histedit_source : a5f1974899bb0f41975417b922306a387822ad1f
It's a wafer thin wrapper around profiler_tracing() and it's only used three
times. Let's just remove it.
Note also that those three uses are the only places where TRACING_EVENT is
used. I wonder if they're really needed...
--HG--
extra : rebase_source : ac70b4c77c4592d96957a8e6249597eafc822fd4
Previously we needed to pass by value and that was causing us to clear out our
prebuilt display list when we actually wanted to keep it around.
The rust code ended up doing a bit of a silly dance but that's better than copying the display list around.
The main changes here are:
- Make QueuedInput store a InputBlockState instead of a CancelableBlockState,
and propagate these changes outwards as necessary.
- Hoist some virtual functions from CancelableBlockState up into InputBlockState.
These are mostly downcast-type functions but also a couple of others
(DispatchEvent and MustStayActive) that are generally applicable to input
blocks and not specific to block cancellation.
- Modify the signatures of a few other functions in InputQueue (such as CanDiscardBlock)
to take a InputBlockState even though all the current call sites pass in a
CancelableBlockState. This will make it easier to plumb in a new non-cancelable
block because the function can still be used without modification.
MozReview-Commit-ID: IzhCxVjkKoj
--HG--
extra : rebase_source : b5b415f829e70ea4e7d52481bc84aa016a55e924
And related methods.
Will allow to directly upload a YUV420 buffer into a D3D11 texture.
MozReview-Commit-ID: FugfJB3818Y
--HG--
extra : rebase_source : faaf2667236699513923aaf76ccc462840182aa6
This patch does the following.
- Renames some ProfilerMarkerPayload subclasses so they all of the form
"FooMarkerPayload", to make the subclass relationship clearer.
(ProfilerMarkerTracing -- now TracingMarkerPayload -- was the worst
offender.)
- Removes ProfilerMarkerImagePayload and TouchDataPayload, neither of which are
used.
- Changes streamCommonProps() to StreamCommonProps().
- Does some minor style and comment fixes in ProfilerMarkerPayload.h.
--HG--
extra : rebase_source : dd732905e96da83bcbf124c70b20011c661fc332
Also tweaks the documentation in FrameMetrics.h to be more detailed and
less misleading.
MozReview-Commit-ID: 183V2Q9kY6C
--HG--
extra : rebase_source : 9fb08cf9c2a9df68637fb26014f637b0cb40b188
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.
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.
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
In gecko, it's possible to generate lots of animation ids per layer if animations are changed.
It also introduces lots of memory allocation/deallocation in CompositorAnimationStorage(HashTable).
Generate fixed animations id per layer should help the memory usage and reduce CPU time for memory allocation.
MozReview-Commit-ID: 1hWUD5gNBJH
--HG--
extra : rebase_source : bd3fcfed5caab5d8edfbd29a8e505daf9e8ff95f
The BasicImageLayer always picks the first frame in image container which is not desired for video playback.
MozReview-Commit-ID: q4QkBT2a7w
--HG--
extra : rebase_source : 732f61eb5ca64a051fc928a1e22706011800d8fb
This patch does the following renamings, which increase consistency.
- GeckoProfilerInitRAII -> AutoProfilerInit
- GeckoProfilerThread{Sleep,Wake}RAII -> AutoProfilerThread{Sleep,Wake}
- GeckoProfilerTracingRAII -> AutoProfilerTracing
- AutoProfilerRegister -> AutoProfilerRegisterThread
- ProfilerStackFrameRAII -> AutoProfilerLabel
- nsJSUtils::mProfilerRAII -> nsJSUtils::mAutoProfilerLabel
Plus a few other minor ones (e.g. local variables).
The patch also add MOZ_GUARD_OBJECT macros to all the profiler RAII classes
that lack them, and does some minor whitespace reformatting.
--HG--
extra : rebase_source : 47e298fdd6f6b4af70e3357ec0b7b0580c0d0f50
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 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
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
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
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
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
If we set a transform in push_stacking_context, it changes the internal
WebRender behaviour to make that stacking context a reference frame, and
things inside it are positioned differently. This is true even if the
transform is an identity transform.
In most cases we are hitting this and sending an identity transform
through, when in fact we want to be sending a None value to WebRender so
that it doesn't create reference frames. This is a partial fix, a proper
fix will be done in bug 1345577 by separating the CSS transform from the
other transforms that FrameLayerBuilder invents.
MozReview-Commit-ID: ElSs3hFMD2D
In addition to updating webrender and webrender_traits, this patch:
- bumps the euclid dependency in webrender_bindings to match webrender
- updates the Cargo.lock files and re-vendors third-party rust packages
- updates the push_yuv_image callers due to an API change in WR cset a4b9e25.
This patch collapses the data from event regions display items that have
the same ASR. However, it only does so if there's no other display items
interleaved in between that forced their own scroll layer data.
MozReview-Commit-ID: IkQSISc2bwc
--HG--
extra : rebase_source : d3001675d516c303d5452aafc57c996192e11e98
We want to collapse all event regions display items with the same ASR
(and that are not interleaved with other APZ-relevant display items),
regardless of the recursion level in the display list. In order to
facilitate this we need to track the last ASR seen in the display list
regardless of the recursion level.
MozReview-Commit-ID: Lw5ZwwmqnkE
--HG--
extra : rebase_source : 14eba8a04a7cbeaa41313aed969484bf5b6f46ad
If we bailed out in ReadbackSurface function, we didn't call
FireDidTransactionCallback properly. Added ScopedFireTransactionCallback
struct to do this right.
MozReview-Commit-ID: DouTY0YVEhU
This allows APZCCallbackHelper to send the SetConfirmedTargetAPZC
message over PWebRenderBridge if webrender is enabled, rather than
assuming the layer manager is a ClientLayerManager and then crashing.
MozReview-Commit-ID: 57o9CaCcbTi
This makes it simpler to reuse this API from WebRenderBridgeParent,
since we can provide a layers id but not a LayerTransactionParent.
MozReview-Commit-ID: DEIGMk9tJEB
This implements some methods exposed on DOMWindowUtils and used by
reftests, for the WebRender codepath. The implementation is very similar
to the implementation in LayerTransactionParent.
MozReview-Commit-ID: HP8OxzIzS7P
This is helpful for reusing the FlushApzRepaints from
WebRenderBridgeParent, since it no longer assumes there's a layers
transaction object.
MozReview-Commit-ID: GVqDDEeZaN3
Both nsIntPoint and IntRect are specializations of template classes (BasePoint
and BaseRect) that are already covered by the corresponding template methods
in LayersLogging.h. Therefore these methods are not needed (and in fact are not
listed separately in LayersLogging.h).
MozReview-Commit-ID: BIZAOFfWCfI
MozReview-Commit-ID: yHXUFw2fx6
***
Bug 1367062 - Change std::map to std::unordered_map in APZCTreeManager
changed gfx/layers/FrameMetrics.h by adding a ScrollableLayerGuidHash class that will be used as the hashing function for std::unordered_maps which use ScrollableLayerGuid as keys.
changed gfx/layers/apz/src/APZCTreeManager.cpp by changing mApzcMap to a std::unordered_map.
changed gfx/layers/apz/src/APZCTreeManager.h by changing mZoomConstraints to a std::unordered_map.
MozReview-Commit-ID: JmoQzh1MvKK
--HG--
extra : rebase_source : cb7bd9419085f83873c9fd019c4a379fae0ee278
The propagation happens via LayerMetricsWrapper or WebRenderScrollDataWrapper.
MozReview-Commit-ID: GBZUnNn3zjN
--HG--
extra : rebase_source : 4c63269480154a95d5faedf1b4972f7d3373cb5a
Also take advantage of the new CoordOf metafunction to combine some of their overloads.
MozReview-Commit-ID: ETybNn7b5ic
--HG--
extra : rebase_source : 5798103462e454dc61abb7c8a26b997f02c8be36
Even if we don't accept the scroll offset from content, we always accept the
new scrollable rect, so to avoid an out-of-bounds scroll offset, we need to
re-clamp it.
MozReview-Commit-ID: 5JbCUYuDPR6
--HG--
extra : rebase_source : 72638713f97b5ab42633580f54b5a4c9dad1a630
We get the progress as |double|, and then pass it to a function by a |float|
type, and then finally cast it back to |double| for the interpolation.
We should avoid casting it back and forth, so change the function argument to
use |double| type for the progress.
MozReview-Commit-ID: 7QzfVBC7hSt
--HG--
extra : rebase_source : 62467bf0a734b650f524af656658cdfdabca2a5c
This is a pre-existing bug that I ran into while exercising the async scrollbar
code on OS X. The LayerTreeState might not be available, so we detect and skip
those layers.
MozReview-Commit-ID: GiHaq7gQLxq
This updates PushStateToWR to actually produce the scrollbar thumb transforms
and append them into the provided transform array.
MozReview-Commit-ID: 14xlpRQXhhq
This allows the APZCTreeManager::PushStateToWR function to also produce a set
of transforms to be applied to scrollbar thumbs. The PushStateToWR function
will be updated in the next patch to actually produce the transforms. This patch
also rearranges code in WebRenderBridgeParent::CompositeToTarget so that either
OMTA or APZ can produce animation updates.
MozReview-Commit-ID: 1ghvVG32TC5
This propagates the animation id for a scroll thumb's stacking context over to
the APZ code, and stores it in the HitTestingTreeNode.
MozReview-Commit-ID: 5O13Xko2Bph
In order to have the scrollbar thumbs reflect the async scroll position, we're
going to re-use the API for OMTA. That is, we set an animation id on the
stacking context for the scroll thumb, and we'll update the transform on the
stacking context at composite time based on the async scroll position. For this
to work we need to ensure that the scroll thumb does in fact have an
animation id set on it.
MozReview-Commit-ID: 6TvRemxRUrR
There were two issues that prevented the static snapshot toolbar and
real chrome toolbar from staying in sync.
1) When a page would resize such as when going fullscreen, if the
root content document was not scrollable, the animator would not receive
root composition page size updates. The page resize is used by the
animator to hide the static snapshot, so it would remain visible while
the real chrome toolbar would be hidden.
2) Certain places in UI java code would toggle the chrome state directly
instead of going through the animator to change the state.
MozReview-Commit-ID: DCQgRFS0UAO
WebRenderImageLayer will create the proper number of imageKey for different video format. Then, send the imageKey to The WebRenderBridgeParent.
MozReview-Commit-ID: HMp4KWCCFqU
Different TextureHost type could use different WR commands. So, make a abstract interface for these different commands.
MozReview-Commit-ID: 63dnOJC2P9r
Add LOCAL_GL prefix for all GL constant value.
Turn to use GL_RED and GL_RB if we use core profile.
Turn to use GL_RGB_422_APPLE instead of GL_YCBCR_422_APPLE for core profile.
MozReview-Commit-ID: FCwbrUEFUxI
This makes UpdateLayerTree synchronous enough to ensure that the layer
transaction from the child reaches the compositor. Given the comment in
http://searchfox.org/mozilla-central/rev/484d2b7f51b7aed035147bbb4a565061659d9278/dom/interfaces/base/nsIDOMWindowUtils.idl#106
this seems to be the original intent of this function anyways. Without this, we
can have a race between the child talking to the compositor and the child
talking to the parent talking to the compositor.
This also changes GetCompositorBridgeChild to work even when the widget doesn't
have a CompositorBridge
This makes UpdateLayerTree synchronous enough to ensure that the layer
transaction from the child reaches the compositor. Given the comment in
http://searchfox.org/mozilla-central/rev/484d2b7f51b7aed035147bbb4a565061659d9278/dom/interfaces/base/nsIDOMWindowUtils.idl#106
this seems to be the original intent of this function anyways. Without this, we
can have a race between the child talking to the compositor and the child
talking to the parent talking to the compositor.
This also changes GetCompositorBridgeChild to work even when the widget doesn't
have a CompositorBridge
In addition to updating gfx/webrender and gfx/webrender_traits, this patch:
- Updates the webrender_bindings Cargo.toml file for version bumps
- Updates the Cargo.lock files and revendors the third-party rust dependecies
- Updates the webrender bindings for a change in the display list construction
and finalization API in WR csets 425155a and 1eb84eb.
We now have to pass around a content size parameter to construct a display list,
and we get back a content size from finalizing the display list. Since we pass
the finalization results over IPC to WebRenderBridgeParent, we need to update
the IPDL as well to pass this around.
- Updates the webrender bindings for a change to scroll_node_with_id in WR cset
48a098f.
- Updates the webrender bindings for a change to push_text in WR cset 3287c15.
This is the WR equivalent (but stripped down to the basics) of the code
in AsyncCompositionManager that advances APZ animations and applies the
async transform to the layer's shadow transform. Currently this doesn't
do anything fancy with the extra scrolling clips, or moving scrollbars,
etc.
MozReview-Commit-ID: BwbNRNHAc6G
This adds an RAII helper and uses it in RenderLayer functions. When APZ
is enabled, the RAII helper pushes a scrolling clip for each scrollable
metrics on the layer. It also pops off the scrolling clips on
destruction. Note that this should happen before any other things are
pushed into the WR display list for the rendering of a layer, since
those things should be subjected to the enclosing scrolling clips.
If APZ is disabled, this skips pushing the scrolling clips.
MozReview-Commit-ID: 1qv9egKbbok
This function is arguably nicer than calling NS_ProcessNextEvent
manually, is slightly more efficient, and will enable better auditing
for NS_ProcessNextEvent when we do Quantum DOM scheduling changes.
This allows the feature to ride the trains later than async scrollbar
dragging itself, if desired.
MozReview-Commit-ID: 73ZlCqM5hMN
--HG--
extra : rebase_source : dabc4a4b72210133d8b62256510213183312f18f
Also add a comment to AsyncDragMetrics documenting that mScrollbarDragOffset
is relative to the thumb's start offset.
MozReview-Commit-ID: uipsOCzs2N
--HG--
extra : rebase_source : 25183e22cb7ffb9995a2594d6aea106cdef7924a
To conserve space in LayerAttributes, we only store the extents along the
relevant axis.
MozReview-Commit-ID: GAL8Oa2NOde
--HG--
extra : rebase_source : 9420d0fb36175e190cbff6e162fd41d8e5240c81
This flag is set to false if there are any conditions that only the main
thread knows about that prevent the thumb from being async-dragged.
MozReview-Commit-ID: Gl7f7bY0QnA
--HG--
extra : rebase_source : 60ab680a3995e3b5c0e1b4482ca0e7142352bbd2
This is preparation for future changes that will add fields to ScrollThumbData
that will be accessed via HitTestingTreeNode.
To accomplish this, this patch also exposes the entire ScrollThumbData via
LayerMetricsWrapper and WebRenderScrollDataWrapper.
MozReview-Commit-ID: 1Ed8Z80Wk1V
--HG--
extra : rebase_source : 86cce84eab0cd8bcd2998f1682137e9514bb1fb5
Also remove a vestigial declaration of the previously removed method
HitTestingTreeNode::GetScrollThumbLength().
MozReview-Commit-ID: 3BvFNeGwPXd
--HG--
extra : rebase_source : 6cc6d2f2e3ecc4dedce2b83f6b0faf819f4be0f8
The patch also renames Layer::SetScrollbarData() to Layer::SetScrollThumbData()
for clarity.
MozReview-Commit-ID: DVwJ3DMl3Zs
--HG--
extra : rebase_source : 7b2bfccf1351c82bb16296635e69d5488c87a50f
This should fix some wrong-looking code that computes the clip for
WebRenderDisplayItemLayer instances. As this code is not exercised very
much it's hard to know if this change is actually correct.
MozReview-Commit-ID: BSsBpBmzWgd
These functions also have built-in assumptions about the stacking
context structure mapping to the layer tree structure which are not
necessarily valid. So we remove these functions and update code that
uses them.
MozReview-Commit-ID: UkXXAF59qv
The only remaining callers of RelativeToParent() are in
StackingContextHelper itself, which we can remove now by having the SCH
take a parent SCH and use it instead of RelativeToParent(). This patch
implements this change.
This makes a failing test pass, because of how preserve-3d container
layers work. Specifically, preserve-3d container layers render their
descendants in z-order, not in tree order. If those children were assuming
that their parent had already pushed a stacking context, that assumption
may have been false because the parent might have not yet been rendered
because of z-ordering. By using the StackingContextHelper chain instead
of the layer tree ancestry, we fix the stacking-context-relative coordinates
being used in the descendant subtree of preserve-3d container layers.
MozReview-Commit-ID: HzZvBuAlMdB
This updates more code that was using RelativeToParent() to use the
stacking context helper's ToRelativeWr* functions instead. This get us
closer to breaking the assumption that the WR stacking context order maps
1:1 to the layer tree structure.
MozReview-Commit-ID: HQrbvCgPOW4
This propagates the StackingContextHelper to the rest of the code that
builds WR display items, because we will need it in future patches to
stop using RelativeToParent.
MozReview-Commit-ID: 3PlQrJRhH36
This cleans up WebRenderRefLayer::RenderLayer to use typed coordinate
systems and the StackingContextHelper. Note that this patch contains a
functional change, because the clip rect pushed no longer includes the
transform on the ref layer itself. It's not clear to me why we were doing
that, and didn't seem correct.
MozReview-Commit-ID: K7FoeLnXc56
This uses the StackingContextHelper and typed helper functions in
WebRenderLayer to simplify WebRenderTextLayer::RenderLayer. It also
removes the implicit assumption in WebRenderTextLayer that the parent
layer pushed a stacking context, which is an assumption we will
probably break in the future.
MozReview-Commit-ID: CARoGVQd56i
This is needed for the next patch, because the bullet frame WR rendering
code will need a StackingContextHelper to pass to the PushGlyphs call.
It also helps with some of the later patches in this series, when we get
rid of the RelativeToParent calls.
MozReview-Commit-ID: Is0aciHhy2N
This is needed in part 3 to update WebRenderTextLayer::RenderLayer, so
that it no longer assumes the parent container layer has pushed a
stacking context, and instead explicitly uses the StackingContextHelper.
MozReview-Commit-ID: 9twUmDgUipX
Need to pass the default transform/opacity to compositor if animations
exist because it is possible that gecko fails to get animated value
after animation sampling, like an animation with delay.
MozReview-Commit-ID: IK06hWvaSPf
Pass empty opacity(transform) in stacking context when there exists opacity(transform) animations and
the final opacity(transform) value will be resolved on the compositor after animation sampling
MozReview-Commit-ID: 6pF9Oe8Ks2I
First, hook the Layer's ClearAnimation API to delete unnecessary
animations in next layer transaction. Second, add another async
DeleteCompositorAnimations API to delete animations on the compositor,
especially calling this API before WebRenderLayerManager got destroyed.
MozReview-Commit-ID: 4mbj5IgsXYa
We are seeing occasional failed release assertions from calling
animation.startTime().get_TimeDuration() in SampleAnimationForEachNode on
Windows.
My theory is that in some circumstances (perhaps graphic-driver related?) when
creating a layer transaction we fail to call Layer::StartPendingAnimations and
end up sending pending animations to the compositor. Prior to bug 1334583 that
would have only triggered a debug assertion so it may have gone unnoticed if it
depends on the system configuration.
This patch makes us check that the startTime is set before we try to access it
in order to avoid triggering a release-time assertion. If the startTime is not
set we will use the hold time which should give us the correct behavior for
a still-pending animation. (Furthermore, the holdTime is set unconditionally
when we create animations so it should be correct -- but even if it were not
set explicitly, its initial zero value would still likely produce a reasonable
result until the start time was updated on a subsequent layer transaction. At
very least, it should not crash. Likewise, if it was set to an incorrect value.)
This patch also strengthens the debug assertion in SampleAnimationForEachNode to
check that not only is start time not-null, but that it is set to a TimeDuration
since MaybeTimeDuration also includes a third uninitialized "None" state.
The patch also adds another gtest that exercises hit testing, and fixes a
coordinate space bug in the gtest fixture.
MozReview-Commit-ID: 3QYTofkKSZj
--HG--
extra : rebase_source : 7108c4b57bdd3ada41dc57ab022825a1057b899d
By passing the startTime as a TimeDuration we are able to represent times in the
distant past (and with the same range as we can represent on the main thread so
that if we do encounter range errors in future, they should not differ between
the main thread and the compositor).
This patch includes a crashtest. I have verified that, without the code changes
included in this patch, this crashtest fails on debug builds on OSX.
MozReview-Commit-ID: EDuKLzfEC0K
--HG--
extra : rebase_source : 1883080fdfac8c33f70698145f21e67cbdfdd4f2
In bug 1223658 we separated out the delay from the start time but we failed to
remove it from this calculation. As a result, when a pending animation begins it
will have the delay applied twice (once here, and once when it is sampled on the
compositor). This will happen until the layer is next updated.
This bug was not exposed by any existing tests since we don't use this code path
when the refresh driver is under test control. Furthermore, the one test that
was supposed to cover this was refactored in such a way that it stopped testing
this code path. That test is restored earlier in this patch series and enabled
in this patch.
MozReview-Commit-ID: B2KR7YaPsMK
--HG--
extra : rebase_source : 6c888252813fbfc01baf5d4bb1728d989ee1586c
The MultiTouchInput::MULTITOUCH_END generated from transitioning from
multiple touch sources to a single source would often cause the content
to shift under the remaining finger which would look like a fling and
cause the content to rapidly scroll. This patch treats the transition from
multiple touch source to a single source as if the touch event were
starting over by resetting all the variables tracking the touch drag
that is in progress.
MozReview-Commit-ID: 42L1Q622fww
David Anderson
Wes Kocher
Kartikaya Gupta
sotaro
Botond Ballo
Carsten "Tomcat" Book
Tom Ritter
Morris Tseng
Nicholas Nethercote
Mats Palmgren
Ehsan Akhgari
David Anderson
Phil Ringnalda
Ethan Lin
Ryan Hunt
vincentliu
Randall Barker
Sebastian Hengst
Alastor Wu
Andrew McCreight
Michael Layzell
Bill McCloskey
Andrew Osmond
Samael Wang
Jeff Muizelaar
Mason Chang
Jacek Caban
Markus Stange
Nathan Froyd
Hiroyuki Ikezoe
Chris Peterson
Matt Woodrow
Jean-Yves Avenard
Alexis Beingessner
domfarolino@gmail.com
JerryShih
peter chang
Christoph Kerschbaumer
Cameron McCormack
Ryan VanderMeulen
Martin Robinson
Martin Robinson
James Willcox
Jonathan Kew
Lee Salzman
Dennis Ek
ohn0
Shing Lyu
Boris Chiou
Iris Hsiao
Brian Birtles
JW Wang