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
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
Milan Sreckovic
Carsten "Tomcat" Book
Kartikaya Gupta
Botond Ballo
Bevis Tseng
Nathan Froyd
vincentliu
Samael Wang
David Anderson
Tom Ritter
Wes Kocher
sotaro
JerryShih
Nicolas Silva
Sebastian Hengst
Ryan VanderMeulen
Kevin Chen
Sylvestre Ledru
peter chang
Ethan Lin
Stone Shih
Ryan Hunt
Andrew Osmond
Ehsan Akhgari
Kris Maglione
Mason Chang
Morris Tseng
Nicholas Nethercote
Mats Palmgren
David Anderson
Phil Ringnalda
Randall Barker
Alastor Wu
Andrew McCreight
Michael Layzell
Bill McCloskey
Jeff Muizelaar
Jacek Caban
Markus Stange
Hiroyuki Ikezoe
Chris Peterson
Matt Woodrow
Jean-Yves Avenard
Alexis Beingessner
domfarolino@gmail.com
Christoph Kerschbaumer
Cameron McCormack
Martin Robinson