The conversion is as follows:
- GraphicsFilter::FILTER_NEAREST == gfx::Filter::POINT
- GraphicsFilter::FILTER_GOOD == gfx::Filter::GOOD
- GraphicsFilter::FILTER_BEST == gfx::Filter::LINEAR
Also typedef GraphicsFilter to gfx::Filter; this will be removed in the next
patch.
These changes mean ToFilter() and ThebesFilter() are no longer needed.
The change breaks some scenarios with APZ scrolling, in particular the code
that layerizes the scroll handoff chain for deeply nested scrollable frames.
--HG--
extra : commitid : KeQX4HyPKXd
In various places SetColor() gets passed an nscolor. These are converted
(either implicitly or explicitly) to a gfxRBGA, and then to a gfx::Color.
This patch changes all these cases to avoid the middle step, by (a)
constructing a gfx::Color directly instead of an nscolor, or (b) by converting
an nscolor with Color::FromABGR().
--HG--
extra : rebase_source : ae423a422b37ada8ca0cb6f130350b4a71d58fc4
gfxIntSize is just a typedef of gfx::IntSize, so this is very mechanical. The
only tricky part is deciding for each occurrence whether to replace it with
IntSize, gfx::IntSize or mozilla::gfx::IntSize; in all cases I went with the
shortest one that worked given the existing "using namespace" declarations.
--HG--
extra : rebase_source : 67fd15f87222b16defa70ef795c6d77dfacf1c36
Remove WrapPreserve3DList() and replaced it by creating a
nsDisplayTransform item for each transformed frame.
- Add an additional item for each top frame extending 3D context to
separate consequence contexts.
- Effective transform of a layer is the accumulation of ancestors in
the same 3D context.
- The layers creating new context and extended by children need a
temporary buffer if it's effective transform is not 2D.
- Clip rects are accumulated along the context chain.
- Visible rects of items are computed from dirty regions of the frame
creating the context and accumulated transforms.
- Bounds of items are computed from accumulated transforms and
accumulated bounds of the descent frames.
- Backface hidden is handled by compositor and BasicLayerManager.
--HG--
extra : rebase_source : 1a894b057a117a8520898c9f83308d92c122b180
Remove WrapPreserve3DList() and replaced it by creating a
nsDisplayTransform item for each transformed frame.
- Add an additional item for each top frame extending 3D context to
separate consequence contexts.
- Effective transform of a layer is the accumulation of ancestors in
the same 3D context.
- The layers creating new context and extended by children need a
temporary buffer if it's effective transform is not 2D.
- Clip rects are accumulated along the context chain.
- Visible rects of items are computed from dirty regions of the frame
creating the context and accumulated transforms.
- Bounds of items are computed from accumulated transforms and
accumulated bounds of the descent frames.
- Backface hidden is handled by compositor and BasicLayerManager.
The special-case was added back when the Fennec dynamic toolbar showing/hiding
behaviour didn't resize the content area. As of bug 1180295 that is no longer
the case, and showing/hiding the dynamic toolbar *does* resize the content area.
Therefore the widget bounds always represents the actual content area and can
be used directly as the composition bounds.
In addition, the special-case code relied on a particular quirk of the Fennec
CSS viewport determination code which was removed in bug 1180267. The quirk was
that the CSS viewport height was always set such that it would cover the
available screen height when the page was zoomed out to the minimum allowed
zoom. This behaviour was technically incorrect as it would ignore any height
properties provided in the meta-viewport tag. Now that this quirk has been
removed, the special-case code breaks because the root frame's height is
independent of the screen height and can result in an incorrect composition
bounds.
--HG--
extra : commitid : 69FDhj50WEN
- Update callsites of Matrix4x4::TransformBounds to use
Matrix4x4::TransformAndClipBounds.
--HG--
extra : rebase_source : a1aa889af56e404b7ca5c7125021171e67a0b8bf
AnimationCollection::HasAnimationOfProperty uses IsFinishedTransition to filter
out transitions that should otherwise be ignored. This is used in the following
places:
1. nsLayoutUtils::HasAnimations
The is only used by nsIFrame::BuildDisplayListForStackingContext to see if
there are any opacity animations
For this case, simply returning *current* animations would be sufficient
(since finished but filling animations should have already filled in the
display opacity)
2. CommonAnimationManager::GetAnimationsForCompositor
This should really only return *current* animations--that is, animations that
are running or scheduled to run. Finished animations never run on the
compositor. Indeed, only *playing* animations run on the compositor but, as
we will see in some of the cases below, it is sometimes useful to know that
an animation *will* run on the compositor in the near future (e.g. so we can
pre-render content).
The places where GetAnimationsForCompositor is used are:
- When building layers to add animations to layers in nsDisplayList--in this
case we skip any animations that aren't playing so if
GetAnimationsForCompositor only returned current animations that would be
more than sufficient.
- In nsLayoutUtils::HasAnimationsForCompositor. This in turn is used:
- In ChooseScaleAndSetTransform to see if the transform is being animated
on the compositor. If so, it calls
nsLayoutUtils::ComputeSuitableScaleForAnimation (which also calls
GetAnimationsForCompositor) and passes the result to
GetMinAndMaxScaleForAnimationProperty which we have already adjusted in
part 4 of this patch series to only deal with *relevant* animations
Relevant animations include both current animations and in effect
animations but we don't run forwards-filling animations on the compositor
so GetAnimationsForCompositor should NOT return them. Current animations
should be enough. In fact, playing animations should be enough but we
might want to pre-render layers at a suitable size during their delay
phase so returning current animations is probably ok.
- In nsDisplayListBuilder::MarkOutOfFlowFrameForDisplay to add a fuzz
factor to the overflow rect for frames undergoing a transform animation
on the compositor. In this case too current animations should be
sufficient.
- In nsDisplayOpacity::NeedsActiveLayer to say "yes" if we are animating
opacity on the compositor. Presumably in this case it would be good to
say "yes" if the animation is in the delay phase too (as it currently
does). After the animation is finished, we should drop the layer, i.e.
current animations should be sufficient.
- In nsDisplayTransform::ShouldPrerenderTransformedContent. As with
nsDisplayOpacity::NeedsActiveLayer, we only need to pre-render
transformed content for animations that are current.
- In nsDisplayTransform::GetLayerState. As with
nsDisplayOpacity::NeedsActiveLayer, we only need to return active here
for current animations.
- In nsIFrame::IsTransformed. Here we test the display style to see if
there is a transform and also check if transform is being animated on the
compositor. As a result, we really only need HasAnimationsForCompositor
to return true for animations that are playing--otherwise the display
style will tell us if we're transformed or not. Returning true for all
current compositor animations (which is a superset of playing), however,
should not cause problems (we already return true for even more than
that).
- In nsIFrame::HasOpacityInternal which is much the same as
nsIFrame::IsTransformed and hence current should be fine.
3. AnimationCollection::CanThrottleAnimation
Here, HasAnimationOfProperty is used when looking for animations that would
disqualify us from throttling the animation by having an out-of-date layer
generation or being a transform animation that affects scroll and so requires
that we do the occasional main thread sample to update scrollbars.
It would seem like current animations are enough here too. One interesting
case is where we *had* a compositor animation but it has finished or been
cancelled. In that case, the animation won't be current and we should not
throttle the animation since we need to take it off its layer.
It turns out checking for current animations is still ok in this case too.
The reasoning is as follows:
- If the animation is newly-finished, we'll pick that up in
Animation::CanThrottle and return false then.
- If the animation is newly-idle then there are two cases:
If the cancelled animation was the only compositor animation then
AnimationCollection::CanPerformOnCompositorThread will notice that there
are no playing compositor animations and return false and
AnimationCollection::CanThrottleAnimation will never be called.
If there are other compositor animations running, then
AnimationCollection::CanThrottleAnimation will still return false because
whatever cancelled the animation will update the animation generation and
we'll notice the mismatch between the layer animation generation and the
animation generation on the collection.
Based on the above analysis it appears that making
AnimationCollection::HasAnimationOfProperty return only current animations (and
simulatneously renaming it to HasCurrentAnimationOfProperty) is safe. Indeed, in
effect, we already do this for transitions but not for animations. This patch
generalizes this behavior to all animations.
This patch also updates test_animations_omta.html since it was incorrectly
testing that a finished opacity animation was still running on the compositor.
Finished animations should not run on the compositor and the changes in this
patch cause that to happen. The reason we don't just update this test to check
for RunningOn.MainThread is that for opacity animations, unlike transform
animations, we can't detect if an opacity on a layer was set by animation or
not. As a result, for opacity animations we typically test the opacity on
either the main thread or compositor in order to allow for the case where an
animation-set opacity is still lingering on the compositor.
GetMinAndMaxScaleForAnimationProperty in nsLayoutUtils uses IsFinishedTransition
to ignore finished transitions since they should not have any effect on current
or future scale values. We can generalize this, however, and say we are only
interested in animations that are *either*:
a) running or scheduled to run in the future, i.e. "current", OR
b) applying a value, including a finished animation with a forwards fill,
i.e. "in effect"
Elsewhere, animations that fulfil *either* of this conditions are referred to as
"relevant animations" so we can simply test for relevance in this function.
The bulk of this commit was generated by running:
run-clang-tidy.py \
-checks='-*,llvm-namespace-comment' \
-header-filter=^/.../mozilla-central/.* \
-fix
The patch works by not handling transform:none specially at all, which
will lead to a scale of 1 (instead of the current 0).
This is the patch that actually fixes the original problem reported in
bug 1122526. This patch also fixes bug 1165196.
This field tells us if this frame metrics should be considered the root APZC for its layers id. Without this there doesn't seem to be a way to compute this from just the layers tree.
We do this by looking at the layer tree after it has been made to see if the root metrics are in it already.
This is needed to ensure that there is always a root AZPC in a process.
ClampRectToScrollFrames generalizes IsRectVisibleInScrollFrames by
returning the clamped rect in scroll frames. IsRectVisibleInScrollFrames
could be implemented by checking whether the clamped rect is empty or
not.
This fixes bug 1153539 with the Firefox download arrow being pixellated
(verified by testing locally).
I also confirmed what happens on a flame device with the transform
unlocking the Firefox OS homescreen (bug 945082 / bug 972310). For that
transform (which had a maximum scale of 2), I see four calls to
GetSuitableScale:
GetSuitableScale: aMaxScale=2.000000, displayVisibleRatio=1.000000
GetSuitableScale: aMaxScale=2.000000, displayVisibleRatio=1.000586
GetSuitableScale: aMaxScale=2.000000, displayVisibleRatio=1.000000
GetSuitableScale: aMaxScale=2.000000, displayVisibleRatio=1.000586
(Presumably the first and third are for width, and the second and fourth
are for height.) I believe this shows that bug 972310 will remain fixed
with this patch.
I chose to use the pres context's visible area rather than the screen
size because it seemed more appropriate, and also because (if memory
serves correctly) it's much cheaper to get.
This patch is a fairly minimal rename of the AnimationPlayer interface. It
leaves a bunch of local variables and helper classes still using the word
"player". These will be addressed in subsequent patches that don't require DOM
peer review.
--HG--
rename : dom/animation/AnimationPlayer.cpp => dom/animation/Animation.cpp
rename : dom/animation/AnimationPlayer.h => dom/animation/Animation.h
rename : dom/webidl/AnimationPlayer.webidl => dom/webidl/Animation.webidl
There are still some other references to "source" in AnimationPlayer such as
HasInPlayerSource and UpdateSourceContent. These are renamed in a subsequent
patch (that doesn't require DOM peer review).
Nicholas Nethercote
Carsten "Tomcat" Book
James Kitchener
Botond Ballo
Kartikaya Gupta
Matt Woodrow
Jonathan Kew
Markus Stange
David Anderson
Thinker K.F. Li
Phil Ringnalda
Olli Pettay
Benoit Girard
Robert Longson
Mats Palmgren
Wes Kocher
Kearwood (Kip) Gilbert
Xidorn Quan
Masayuki Nakano
Jonathan Watt
Brian Birtles
CJ Ku
Robert O'Callahan
Seth Fowler
Birunthan Mohanathas
Kyle
Juan Gomez
Lee Salzman
L. David Baron
Daniel Holbert
Ryan VanderMeulen
Cameron McCormack
Timothy Nikkel
Kyle Zentner
Ting-Yu Lin
Danilo Cesar Lemes de Paula