I think there are three advantages of this change:
1. removes some dependencies from layout / painting code to pre-computed
value stuff in the style system;
2. makes it easier to audit usage of specific fields in style structs
(which is probably a side effect of the first one);
3. potentially improves performance since it doesn't go through the
unnecessary general logic in ExtractComputedValue.
Also, combined with the part before, we get a unified list for visited-
dependent properties so that we can ensure the assertion here and the
style difference calc code are consistent.
MozReview-Commit-ID: 5B9aN7CfRgI
--HG--
extra : rebase_source : ac80eaea2474b9ec4b47b1cc9a5bdd2e61f6ec4d
Simply move ComputeHTMLReferenceRect and ComputeSVGReferenceRect from
nsCSSClipPathInstance to nsLayoutUtils to reuse the code in both clip-path and
mask.
MozReview-Commit-ID: 59LofAeEhKQ
--HG--
extra : rebase_source : d974c7e2170a43242ae839c34ae5cef946d4264a
This patch is written with the help of the following script.
function rename() {
find .\
-type f\
! -path "./obj*"\
! -path "./.git"\
! -path "./.hg"\
\( -name "*.cpp" -or\
-name "*.h" \)\
-exec sed -i -e "s/$1/$2/g" "{}" \;
}
rename "css::Side" "Side"
MozReview-Commit-ID: DPV6vivpPUp
--HG--
extra : rebase_source : 9c4f66dc9d2b26c89a4517fba4ff9c5db413411b
Expose requestIdleCallback on Window and implement running callbacks
in idle periods by posting rICs to the main threads idle queue.
MozReview-Commit-ID: KSYQsyaZ6is
--HG--
extra : rebase_source : 6abd41c2de96b39004f1b2c3c740e81de570970c
Expose requestIdleCallback on Window and implement running callbacks
in idle periods by posting rICs to the main threads idle queue.
MozReview-Commit-ID: KSYQsyaZ6is
--HG--
extra : rebase_source : 4bdd578b654d05cab600489d30d859452d1bc888
This patch introduces a new functions named HasEffectiveAnimationOfProperty.
This function checks that a given CSS property is overridden by !important
rules.
On the other hand, now KeyframeEffetReadOnly::HasAnimationOfProperty() does
just check that the effect has a given CSS property. This is used to create
a stacking context because we should create a stacking context for opacity or
transform animations even if the property is overridden by !important rules.
Note about no-stacking-context-(opacity|transform)-removing-animation-in-delay.html
Before this patch we don't create any stacking context for animations overridden
by !important rules, but after this patch we do create a stacking context for
such animations. As a result, in the test case we did paint a stacking context
in the first rAF callback and then in the second rAF callback we did clear the
painted stacking context. Unfortunately sometimes the second rAF callback was
called prior to clear the stacking context on the compositor because of
compositor delay. To avoid this situation, we have to wait for MozAfterPaint
instead of rAF callback.
MozReview-Commit-ID: AG1Y0IgoB3U
This patch introduces a new functions named HasEffectiveAnimationOfProperty.
This function checks that a given CSS property is overridden by !important
rules.
On the other hand, now KeyframeEffetReadOnly::HasAnimationOfProperty() does
just check that the effect has a given CSS property. This is used to create
a stacking context because we should create a stacking context for opacity or
transform animations even if the property is overridden by !important rules.
MozReview-Commit-ID: AG1Y0IgoB3U
KeyframeEffectReadOnly::HasAnimationOfProperty() calls GetAnimationOfProperty()
which checks mWinsInCascade flag and the mWinsInCascade flag is set to true
only if the effect is in-effect.
That means nsLayoutUtils::HasCurrentAnimationOfProperty() actually represents
that a given frame has at least one animation which is current and *in-effect*
(i.e. active).
MozReview-Commit-ID: 93rMMmzrBMi
--HG--
extra : rebase_source : c48167d874aa243ab070d0aa64876307748e3493
After using enum class, a switch-case warning in CombineBreakType is caught.
This is one of such kind safty checks that we would like to gain.
Fix it by adding default case for switch-case in CombineBreakType.
MozReview-Commit-ID: BdS3LPN6qzX
--HG--
extra : rebase_source : 17f24a0d482ed6eb51b23e6942d0ac1c87375e0b
This patch is generated by the following commands (note: if you're running
using OS X's sed, which accepts slightly different flags, you'll have to
specify an actual backup suffix in -i, or use gsed from Homebrew):
hg stat -c \
| cut -c 3- \
| tr '\n' '\0' \
| xargs -0 -P 8 gsed --follow-symlinks 's/\bnsCSSProperty\b/nsCSSPropertyID/g' -i''
Then:
hg mv layout/style/nsCSSProperty.h layout/style/nsCSSPropertyID.h
... and finally, manually renaming nsCSSProperty in the include guard in
nsCSSProperty.h.
MozReview-Commit-ID: ZV6jyvmLfA
--HG--
rename : layout/style/nsCSSProperty.h => layout/style/nsCSSPropertyID.h
The merge from inbound to central conflicted with the merge from
autoland to central, it appears. Per tree rules, the commit from the
autoland repo wins and the inbound commit gets backed out.
CLOSED TREE
--HG--
extra : amend_source : 927e1cdfa8e55ccbd873d404d905caf6871c8c4f
extra : histedit_source : 07095868c3f767258e1d7d2645193bf4811b13bb%2Ca49ae5a28bf6e67298b6208ee9254c25a2539712
This patch is generated by the following commands (note: if you're running
using OS X's sed, which accepts slightly different flags, you'll have to
specify an actual backup suffix in -i, or use gsed from Homebrew):
hg stat -c \
| cut -c 3- \
| tr '\n' '\0' \
| xargs -0 -P 8 gsed --follow-symlinks 's/\bnsCSSProperty\b/nsCSSPropertyID/g' -i''
Then:
hg mv layout/style/nsCSSProperty.h layout/style/nsCSSPropertyID.h
... and finally, manually renaming nsCSSProperty in the include guard in
nsCSSProperty.h.
MozReview-Commit-ID: ZV6jyvmLfA
--HG--
rename : layout/style/nsCSSProperty.h => layout/style/nsCSSPropertyID.h
The modification to nsAbsoluteContainingBlock.h and nsBlockFrame.cpp are
needed to fix the build error due to the file order changed in the unified
build.
The #includes are fixed by the following script:
function rename() {
find .\
-type f\
! -path "./obj*"\
! -path "./.git"\
! -path "./.hg"\
\( -name "*.cpp" -or\
-name "*.h" \)\
-exec sed -i -e "s/$1/$2/g" "{}" \;
}
rename "nsHTMLReflowMetrics\.h" "mozilla\/ReflowOutput\.h"
MozReview-Commit-ID: KWvcG3UtKNn
--HG--
rename : layout/generic/nsHTMLReflowMetrics.cpp => layout/generic/ReflowOutput.cpp
rename : layout/generic/nsHTMLReflowMetrics.h => layout/generic/ReflowOutput.h
extra : rebase_source : dc62fb3ad4d95e732e5985c7ab9f757a0e23abcb
This preference was added in bug 747274, and the need for it (i.e.,
having it default to a different value on Android) was removed a few
weeks later in bug 750598.
Whether we honor the preference depends on which drawing function we go
through, which bug 720531 will make even more inconsistent than it
already is (by causing it to be honored for border-image-repeat: space,
but not other values of border-image-repeat).
Rather than trying to clean it up, it seems best to remove it, since its
initial purpose appears to have been having a different default on
Android, which we longer need.
MozReview-Commit-ID: IFW2Ukwx4fH
--HG--
extra : transplant_source : q1%22Ad%D2%AF%8E%E5%E2%257C%A3%9F%95%DB%A5%92%B2
We want to know that an nsIFrame has a transform or opacity animations
regardless of its state, e.g., running on the main-thead, paused or
finished but in fill:forwards state, to create a stacking context
for the animation.
MozReview-Commit-ID: mNYsd5RO3u
--HG--
extra : rebase_source : 19f88d9f77f3c329f36a6505c6335bae64050a22
The function doesn't need to be a non-static member of nsIPresShell: it only checks if the document of the passed in element matches the presshell's document, and then the remaining code could be static. It has only one user, nsDocumentViewer::FindContainerView, and it doesn't care about the specific presshell, it just wants the primary frame, so it doesn't need the document check.
This lets us simplify nsDocumentViewer::FindContainerView because it had to jump through hoops to get the presshell.
The function doesn't need to be a non-static member of nsIPresShell: it only checks if the document of the passed in element matches the presshell's document, and then the remaining code could be static. It has only one user, nsDocumentViewer::FindContainerView, and it doesn't care about the specific presshell, it just wants the primary frame, so it doesn't need the document check.
This lets us simplify nsDocumentViewer::FindContainerView because it had to jump through hoops to get the presshell.
nsLayoutUtils::IsRectVisibleInScrollFrames() was used only by
SelectionCarets which was removed in bug 1221459.
MozReview-Commit-ID: 4dQAq1umHY7
--HG--
extra : rebase_source : 9c35effc9ac44bb9de5df1e4ddfc0d32edcfb9c9
It's not obvious that it does this (unless you read the comment or the code), and we don't gain much by doing it.
Also we need to split it up for the next patch in this bug.
Without this patch, patch 2 will cause assertions since
nsFrame::DestroyFrom calls nsFrame::HasCSSAnimations (at a time when the
child frame has been destroyed), which calls into the code modified in
patch 2 to call GetStyleFrame.
--HG--
extra : commitid : EkhtcNIf7ye
Temporarily rename GetDisplayPort to GetDisplayPortRelativeToScrollPort for the duration of this patchset.
This means that every caller of GetDisplayPort is guaranteed to be touched by this patchset (assuming it compiles), and thus each call site can be checked in review to make sure it is relative to the correct coordinate system.
This makes the one caller that needs the displayport rect have to ask for it seperately.
The reason for this is later in the patch series we need to add "RelativeToScrollFrame/Port" to all displayport getters, but there is no semantically good way to do that to the name GetOrMaybeCreateDisplayPort.
This makes the one caller that needs the displayport rect have to ask for it seperately.
The reason for this is later in the patch series we need to add "RelativeToScrollFrame/Port" to all displayport getters, but there is no semantically good way to do that to the name ViewportHasDisplayPort.
This makes it clearer whether we're just checking if a displayport exists,
or we're actually consuming its value.
--HG--
extra : source : 70bb222e860669a6cf6e803dbd57f088ca4fbc04
AutoTextRun now only needs a DrawTarget instead of an nsRenderingContext, and
similar nsRenderingContext/gfxContext-to-DrawTarget replacements can be
propagated a long way up the call graph. This patch replaces 93 occurrences of
nsRenderingContext and 135 occurrences of gfxContext with DrawTarget; that's
13% of them.
The patch is mostly plumbing changes. A couple of not-entirely-plumbing
changes:
- It adds a comment about the null check in
gfxGlyphExtents::GetTightGlyphExtentsAppUnits().
- A couple of functions simply had an unused gfxContext or nsRenderingContext
parameter removed, e.g. SetLineBreaks().
--HG--
extra : rebase_source : 8f56994bb4d254a86788b17ab2864ebc758a7e6b
The two flags combined used to be represented by just RENDER_IGNORE_VIEWPORT_SCROLLING. Until http://hg.mozilla.org/mozilla-central/rev/99279c1c33cc (bug 590294) split RENDER_DOCUMENT_RELATIVE out. It split out the requested rect to be document relative. But it also split out the part about "drawing the document as if it had not been scrolled" with the new flag, but the comments for that part didn't get updated.
The names of the flags are perhaps inaccurate, but changing that requires changing a lot more code.
We may want to do this for fixed pos frames in all documents (not just root documents). However, this patch only maintains the previous behaviour on purpose.
Instead of returning the root scroll frame if we encountered the root frame (which is the parent of the root scroll frame).
This allows the use of GetNearestScrollableFrame to walk up the frame tree without getting into a infinite loop going from root scroll frame to root frame and back.
This regresses bug 1105823 in that fixed pos frames will no longer find the root scroll frame of their document. The next patch will fix that.
The only other type of frame that will be affected when calling GetNearestScrollableFrame are viewport (root) frames. However, the only user of SCROLLABLE_ALWAYS_MATCH_ROOT (APZCCallbackHelper) calls GetNearestScrollableFrame on the result of a hit test on a display list. Viewport frames never create any display items whose HitTest function could return the viewport frame.
Removing the "stop at ancestor" parameter from functions that compute AGR meant that nsLayoutUtils::GetAnimatedGeometryRootFor could no longer pass the display item's reference frame as the "stop at ancestor" which meant that the AGR could cross the reference frame for the item, which we don't want. So we make transformed frames into AGRs.
This makes the computation of display items whose frames are transformed tricky. We need the AGR of the transform item to be the ancestor AGR, not the underlying frame of the transform item (which is now an AGR). So we modify nsLayoutUtils::GetAnimatedGeometryRootFor to handle this. (The patch from bug 1205087 didn't suffer from this problem because it special cased the computation of the AGR of transform items. Leaving anybody who called nsLayoutUtils::GetAnimatedGeometryRootFor to get the wrong result.)
The computation of the AGR for scroll metadata in ContainerState::ProcessDisplayItems specifically bypassed nsLayoutUtils::GetAnimatedGeometryRootFor to avoid it's special processing of fixed background items. However we do want the AGR for scroll metadata to do this special processing of transform items. So we add a flag to bypass the fixed background behaviour and use it for the scroll metadata AGR.
This removes the "aStopAtAncestor" argument to agr computing functions. In most cases an AGR was passed for the stop at ancestor, so we'd stop at it anyway since it was an AGR. Most of the remaining cases the root reference frame was passed. And in a few cases something else was passed, which we probably don't want (returning something that isn't an AGR and isn't the root reference frame as an AGR).
The ShouldFixToViewport case is a little tricky. We want to get the AGR of the nearest viewport frame, but only if we don't have to cross our root reference frame to get it. This happens in practice for example when a select dropdown has background-attachment: fixed inside it.
Except for the ShouldFixToViewport bit, this patch is a subset of part 3 in bug 1205087 (which has more changes, and has been temporarily backed out, the remaining bits can hopefully land soon).
The ShouldFixToViewport part is by Timothy Nikkel <tnikkel@gmail.com>
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
This commit was generated using the following script, executed at the
top level of a typical source code checkout.
# Don't modify select files in mfbt/ because it's not worth trying to
# tease out the dependencies currently.
#
# Don't modify anything in media/gmp-clearkey/0.1/ because those files
# use their own RefPtr, defined in their own RefCounted.h.
find . -name '*.cpp' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
grep -v 'mfbt/RefPtr.h' | \
grep -v 'mfbt/nsRefPtr.h' | \
grep -v 'mfbt/RefCounted.h' | \
grep -v 'media/gmp-clearkey/0.1/' | \
xargs perl -p -i -e '
s/mozilla::RefPtr/nsRefPtr/g; # handle declarations in headers
s/\bRefPtr</nsRefPtr</g; # handle local variables in functions
s#mozilla/RefPtr.h#mozilla/nsRefPtr.h#; # handle #includes
s#mfbt/RefPtr.h#mfbt/nsRefPtr.h#; # handle strange #includes
'
# |using mozilla::RefPtr;| is OK; |using nsRefPtr;| is invalid syntax.
find . -name '*.cpp' -o -name '*.mm' | xargs sed -i -e '/using nsRefPtr/d'
# RefPtr.h used |byRef| for dealing with COM-style outparams.
# nsRefPtr.h uses |getter_AddRefs|.
# Fixup that mismatch.
find . -name '*.cpp' -o -name '*.h'| \
xargs perl -p -i -e 's/byRef/getter_AddRefs/g'
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
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.
- 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.
The bulk of this commit was generated by running:
run-clang-tidy.py \
-checks='-*,llvm-namespace-comment' \
-header-filter=^/.../mozilla-central/.* \
-fix
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 makes APZ behave nicely with most uses of a css transform:scale.
Summary of changes:
- FrameMetrics::mCumulativeResolution now includes the css-driven resolution
in addition to the pres-shell resolution.
- Displayports are now stored in Screen pixels rather than Layer pixels.
This is what we want anyways (as we'd like the displayport size to remain
constant as a fraction of the screen size), but it was necessary to make
this change as part of this patch because continuing to store them in
Layer pixels in the presence of a css-driven resolution would have
required a bunch of infrastructure to implement correctly.
Remaining work:
- Layout painting a scrollable layer at a resolution different from the
scale induced by the css transform causes problems. These will go away
with bug 1076192.
- Different resolutions on the x and y axes are not supported. This is
tracked by bug 1039967.
This makes APZ behave nicely with most uses of a css transform:scale.
Summary of changes:
- FrameMetrics::mCumulativeResolution now includes the css-driven resolution
in addition to the pres-shell resolution.
- Displayports are now stored in Screen pixels rather than Layer pixels.
This is what we want anyways (as we'd like the displayport size to remain
constant as a fraction of the screen size), but it was necessary to make
this change as part of this patch because continuing to store them in
Layer pixels in the presence of a css-driven resolution would have
required a bunch of infrastructure to implement correctly.
Remaining work:
- Layout painting a scrollable layer at a resolution different from the
scale induced by the css transform causes problems. These will go away
with bug 1076192.
- Different resolutions on the x and y axes are not supported. This is
tracked by bug 1039967.
The PositionedEventTargeting code allows input events to be dispatched to a
target not directly under the input event point. However, the coordinates of the
input event can then end up outside the bounding rect of the event target. This
state is generally unexpected by web content and may cause compatibility issues.
Fennec's front-end code used to deal with this by repositioning the input event
coordinates to be inside the bounding rect; now that Fennec is using the shared
C++ code we need to have that code here. This behaviour is guarded by a pref and
disabled by default (but enabled on Fennec).
This patch adds a method to nsLayoutUtils, alongside the existing
HasCurrentAnimations, that returns true if there exists an unfinished animation
on the element for the specified property.
According to roc the content viewer position doesn't mean much; only the size is
set to anything meaningful. Therefore using the position from the content viewer
bounds is not a good idea, and we should use the position from the frame bounds
instead. This patch also changes GetContentViewerBounds to GetContentViewerSize
so that it's harder to accidentally use the position in other places.
