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
PLayerTransaction's constructor was previously synchronous so we could
return a TextureFactoryIdentifier. This is quite reliably available
already in the case of opening a tab, due to RenderFrameParent knowing
which compositor it is attached to, so we can make the constructor
asynchronous.
In the top-level widget case, we add a new synchronous message to find
the TextureFactoryIdentifier.
Because ProfilerMarkerPayload is the main type defined in these files, and
because the next patch is going to introduce ProfilerMarker.{h,cpp}, which
would be confusingly similar to the old names.
--HG--
rename : tools/profiler/core/ProfilerMarkers.cpp => tools/profiler/core/ProfilerMarkerPayload.cpp
rename : tools/profiler/public/ProfilerMarkers.h => tools/profiler/public/ProfilerMarkerPayload.h
extra : rebase_source : df22a2ab3867650348ae78fe959ff0366aff230b
PLayerTransaction's constructor was previously synchronous so we could
return a TextureFactoryIdentifier. This is quite reliably available
already in the case of opening a tab, due to RenderFrameParent knowing
which compositor it is attached to, so we can make the constructor
asynchronous.
In the top-level widget case, we add a new synchronous message to find
the TextureFactoryIdentifier.
--HG--
extra : rebase_source : 4b29b859aa5745fabe3db0fe68742328fc0af175
This is functionally equivalent since one variant of the
PushStackingContext was already delegating to the other (in
DisplayListBuilder).
MozReview-Commit-ID: 8PfMm3bHeSZ
This class is a RAII class that can be used to push a stacking context
with properties from a WebRenderLayer. It can also then be used to
convert rects in the layer coordinate system to be relative to the
stacking context, which is what we want for passing to WR.
MozReview-Commit-ID: 1WVrfRYqLqc
As we are often converting from LayoutDevicePixel to LayerPixel types
in WebRenderDisplayItem code, I added a convenience overload of
RelativeToParent that takes a LayoutDeviceRect and returns a LayerRect,
even though this is a potential footgun if abused.
MozReview-Commit-ID: DABAWdOBsbV
This extracts a strongly-typed ClipRect() function from GetWrClipRect.
GetWrClipRect is left as a weakly-typed wrapper for existing call sites,
and also does the necessary reference point conversions.
MozReview-Commit-ID: EuyzYIYLR6S
This moves the bulk of the meaningful work done by GetWrRelBounds into
strongly-typed helper functions. GetWrRelBounds is left as a wrapper so
call sites don't need to be updated yet. Note also that the
strongly-typed functions do not do any conversions from one reference
point from another (e.g. by calling the RelativeToXXX functions).
MozReview-Commit-ID: B3nPbOJOf9o
In addition to updating the Cargo.toml/Cargo.lock files and generated FFI header,
this patch also:
- Updates a couple of field names in the IPC serialization code as a result
of webrender cset 8ca10a8
- Removes z-index related goop, since it's no longer needed as of webrender
cset c872232
When APZ traverses a tree using LayerMetricsWrapper, the layer tree
already has its RefLayers connected because of the in-scope
AutoResolveRefLayers. When traversing using the
WebRenderScrollDataWrapper though, this is not the case, and we need to
explicitly jump from one layer tree to another during the walk.
Thankfully we don't require upwards traversal in the tree or this would
be much more complicated.
MozReview-Commit-ID: 8gbvUlzghLx
This puts all the other things that APZ needs into the
WebRenderScrollData object. The main exception is the scroll clip - I'm
not totally sure how that will be handled yet, so for now we just return
no clip from WebRenderScrollDataWrapper.
MozReview-Commit-ID: 1IhGhSFiPYi
This mainly implements the GetLastChild and GetPreviousSibling functions
in the WebRenderScrollDataWrapper, and adds helper functions that are
needed to make that possible. This allows the WebRenderScrollDataWrapper
to simulate a full "LayerMetrics" tree using the information in the
underlying WebRenderScrollData object.
MozReview-Commit-ID: K82Ud2gAo8K
This adds the WebRenderScrollDataWrapper class which is
template-compatible with LayerMetricsWrapper. While the
LayerMetricsWrapper operates on an underlying layer tree, the
WebRenderScrollDataWrapper will simulate a layer tree based on an
underlying WebRenderScrollData object. The class is stubbed out here,
functions will be implemented in subsequent patches.
MozReview-Commit-ID: 9exnFRI6tOW
This further abstracts away the direct dependence on particular layer
types. This is needed in particular for the APZCTreeManager call site
since it will need to operate on non-layer-tree data which is hard if it
relies specifically on RefLayer.
MozReview-Commit-ID: zbK3oTNHJc
Currently the public UpdateHitTestingTree function takes a Layer* which
assumes there is a layer tree to traverse. However, with WebRender, that
is not the case. This patch has two conceptual changes.
The first change is to extract the innards of UpdateHitTestingTree to take
a LayerMetricsWrapper instead of a Layer* and traverse the layer tree
using that. This was already mostly happening but this makes the
Layer*/LayerMetricsWrapper boundary a little more explicit.
The second change is to make the extracted helper function templated, so
it accepts anything that is template-compatible with
LayerMetricsWrapper. I chose to use a template rather inheritance to
avoid the performance hit of virtual functions, since this code runs
relatively often.
This paves the way for adding a different kind of tree-traversal object
instead of the LayerMetricsWrapper while reusing the same logic to build
the hit-testing tree and APZC nodes.
MozReview-Commit-ID: 6SmnX6Bn2QV
This adds a WebRenderScrollData class (which contains a list of
WebRenderLayerScrollData objects, among other things), and adds it to
the DPEnd/DPSyncEnd messages sent across PWebRenderBridge. These classes are
skeletons for now (more stuff will be added to them in future patches).
MozReview-Commit-ID: 9duxwlUpdu7
Android Dynamic Toolbar v3 toolbar height between controller
and compostior threads would get out sync during animation. Added code
to insure they stay in sync while the compositor thread is updating the
toolbar height during an animation. Also, when the controller thread was
canceling an animation, the compositor thread was not checking that it
was still animating before unlocking the toolbar.
MozReview-Commit-ID: 1TSfaRD0lMj
Note that in upstream WR the push_scroll_layer API has already been
renamed to push_clip_node, so conceptually the same API covers both
"scrolling clips" (aka scroll layers) and non-scrolling clips. So using
the same underlying API for two different WebRenderAPI.h functions makes
sense.
MozReview-Commit-ID: He7jBVqZuLn
Animations in content side could be removed easily by changing CSS, but the
CompositorAnimationStorage in parent side doesn't get updated. Therefore,
we store the layer's CompositorAnimationsId before layer is destroyed in
WebRenderLayerManager and then send out these discarded ids to parent on
the next layer transaction.
MozReview-Commit-ID: D4kbYsgLl4P
This removes the call to push_scroll_layer in wr_push_stacking_context, so that
it's now possible to push a stacking context without necessarily pushing a
scroll layer. There is already a separate function to push a scroll layer so the
call sites can do that. This patch just changes all the call sites that were
pushing a stacking context to also push a scroll layer, so there should be no
functional change. Future patches can remove the spurious scroll layers.
MozReview-Commit-ID: FtCkc9JQd8l
This introduces two new statistics to the overlay. The first is the ratio of
pixel shader invocations (as determined by the GPU) to the number of pixels we
determined need to be redrawn. The ideal ratio is 1.0, indicating that we
filled every pixel exactly once. Anything over 1.0 indicates overdraw.
We also add the ratio of shaded pixels to window size. This indicates how well
we computed the invalid region, and whether or not we overfilled that
region.
Note that the OpenGL and Basic compositors do not yet query the GPU for
this statistic, so they will estimate shader invocations by the area of
DrawQuad calls.
Finally, we remove the feature where layout can request the most
recent overdraw statistic. It was not implemented on all compositors, and the
only test that used it was disabled.
--HG--
extra : rebase_source : 448a162998921974575a1a988bcfde52c959d3ed
This factors out ID3D11Query handling, and makes EndFrame() shorter by
moving out presentation code.
--HG--
extra : rebase_source : c23547a16f9496caa2b83fca8e41d2b4e14bea3a
This call should be a no-op in the real world, and should be safe to
remove. The patch also adds an assert to ensure that the call is
effectively a no-op.
MozReview-Commit-ID: BXdcnHULWW2
--HG--
extra : rebase_source : 03c57d2d6dbfb1d330ce7eab6d842d8375d33208
The goal of this patch is to remove the call to the sync IPC
GetCompositorOptions message from TabChild::InitRenderingState. In order
to this, we have InitRenderingState take the CompositorOptions as an
argument instead, and propagate that backwards through the call sites.
Eventually we can propagate it back to a set of already-sync IPC
messages in PCompositorBridge that are used during layers id
registration (NotifyChildCreated, NotifyChildRecreated, etc.). Therefore
this patch effectively piggybacks the CompositorOptions sync IPC onto
these pre-existing sync IPC messages.
The one exception is when we propagate it back to the AdoptChild call.
If this message were sync we could just use it like the others and have
it return a CompositorOptions. However, it is async, so instead we add
another call to GetCompositorOptions here temporarily. This will be
removed in the next patch.
MozReview-Commit-ID: AtdYOuXmHu4
--HG--
extra : rebase_source : 5b80831cf84d3a4b57b2214a12ccf8a896cfa3a7
David Anderson
Andrew McCreight
JW Wang
Botond Ballo
Wes Kocher
Brian Birtles
Kartikaya Gupta
Ethan Lin
Randall Barker
Shing Lyu
Iris Hsiao
Markus Stange
Phil Ringnalda
David Anderson
Nicholas Nethercote
sotaro
Carsten "Tomcat" Book
Lee Salzman
Alexis Beingessner
Ben Kelly
Mason Chang
Sebastian Hengst
Jeff Muizelaar
peter chang
Jonathan Watt
vincentliu
Jamie Nicol
Morris Tseng
Gregory Moore
Bob Owen
Kevin Chen
Jeff Gilbert
James Willcox
Tom Ritter
Matt Woodrow
Bill McCloskey
Miko Mynttinen
Hiroyuki Ikezoe
Bas Schouten
Ehsan Akhgari
Andrew Osmond