This allows us to allocate an Android SurfaceTexture in the compositor process as well
as an accompanying Surface. We can then transfer the Surface back to the content process
via binder, where it can be used for things like WebGL and video decoding.
Each SurfaceTexture/Surface pair has a unique handle. We use this handle in
layer transactions to locate the SurfaceTexture for a given Surface and composite it
appropriately.
MozReview-Commit-ID: 68VSbXdfsMH
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 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
The reason of this change is the same as for Part 2, except that this commit fixes
nsSVGPaintServerFrame::GetPaintServerPattern rather than PaintSVG.
Commit-ID: 691YrKZ0Lm9
MozReview-Commit-ID: KSnFhCndFUk
--HG--
extra : rebase_source : 3397613129fff6023833cdc3bd639f0d2b151652
extra : source : fa29f1920a88d88bcf0f5239462d32ee8955895c
The DrawResult return was not in fact anything to do with the success or
failure of that method, but was actually passing out a very specific piece of information
about the success or failure of any imagelib drawing that may not have occurred
under the various PaintSVG calls.
The signature of PaintSVG is changed from
DrawResult PaintSVG(...., uint32 flags);
to
void PaintSVG(...., imgDrawingParams& aPackage);
imgDrawingParams wraps DrawResult and imgIContainer::FLAG_* as a pack, pass through
PaintSVG to imagelib draw calls under beneath.
MozReview-Commit-ID: IOq2evUAOQF
--HG--
extra : rebase_source : 66c9a9e391c2f9e142575f42fd47b37334ec5752
extra : source : 97a08873177c0f18edffdb1b5589c77843a50553
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
SkOpts.cpp will call Init_crc32() on aarch64 build. So we should add SkOpts_crc32.cpp to aarch64 sources.
MozReview-Commit-ID: BInjMXYA1jH
--HG--
extra : rebase_source : e6f0236df1cd9035255689fff9683f86ed967f59
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
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
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
Update for blob image and yuv image interface changes.
The implementation of the blob image renderer is empty now. It will need to be
updated in another commit. This also adds wr_dp_push_yuv_*_image() functions in
WebRenderAPI.
There is no change for |./mach vendor rust|.
MozReview-Commit-ID: Kk2rPAmt3vF
The new parameter "channel index" is used to select the specific channel data from a multiple channel textureHost(e.g. yuv format textureHost).
MozReview-Commit-ID: Ey1cA25Z6WH
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
Apparently passing a nullptr to slice::from_raw_parts is unsafe. So we
wrap those calls into a helper function that returns an empty slice
instead.
MozReview-Commit-ID: EAp90FKb8cQ
Wes Kocher
Randall Barker
James Willcox
Nathan Froyd
Andrew Osmond
Jan Beich
Kartikaya Gupta
Carsten "Tomcat" Book
Cameron McCormack
Manish Goregaokar
Ryan VanderMeulen
David Anderson
Mason Chang
Lee Salzman
Jonathan Kew
Iris Hsiao
Hiroyuki Ikezoe
cku
Daosheng Mu
peter chang
Brian Birtles
Botond Ballo
Jeff Muizelaar
Ting-Yu Lin
Jim Chen
Makoto Kato
Phil Ringnalda
David Anderson
Nicholas Nethercote
Sebastian Hengst
JW Wang
Nazım Can Altınova
Ethan Lin
JerryShih
Shing Lyu
sotaro
Jamie Nicol
Alexis Beingessner