- Extended nsIScrollableFrame and nsGfxScrollFrame to return destination
of smooth scrolls which are to be animated on the compositor thread.
- Added apz.smooth_scroll_repaint_interval preference.
- Implemented AsyncPanZoomController::PanZoomState::SMOOTH_MSD_SCROLL state
and AsyncPanZoomController::SmoothScrollAnimation class to animate smooth
scroll animations on the compositor thread.
- Extended FrameMetrics to report requests for smooth scrolls to be animated
on the compositor thread and their corresponding destination positions.
- AsyncPanZoomController now checks FrameMetrics for requests to perform
smooth scrolling on the compositor thread. It will ensure that they
are cancelled as needed by mousewheel, touchpanel, keyboard, and
CSSOM-View instant scrolling DOM methods.
- The layout/generic/test/test_scroll_behavior.html mochitest has been
commented as depending on Bug 1062609 before being enabled for APZ.
This is the start of the changes to caret-drawing proper.
The idea is to combine GetCaretFrame and GetCaretRect into a method
GetPaintGeometry which looks like GetGeometry but returns values
needed for painting (i.e. including bidi decorations, and returning
a null frame if we're not supposed to paint due to specific caret
state, e.g. in the "off" phase of the blink cycle).
Mostly a straightforward refactoring but there are a few interesting changes:
-- nsDisplayCaret stores its bounds instead of getting them from nsCaret on
demand. Eventually those bounds will not be stored in nsCaret at all.
-- nsDisplayCaret::GetBounds returns true for aSnap. nsCaret draws snapped
rects, so why not.
-- I removed "if (caretRect.Intersects(aDirtyRect))" in EnterPresShell.
As far as I can tell, this check is incorrect because it doesn't take
transforms into account. Since there's at most one drawn caret per window,
hence we do this at most once per paint, I don't think there's any real
performance advantage to having this check.
--HG--
extra : rebase_source : c98d3a5994478b482d19cc2e2ac83ab51bd17e00
This patch started an attempt to remove nsFrameSelection.h from nsCaret.h
and metastasized into a rather large refactoring patch that removed it
from some other header files as well, and changed nsFrameSelection::HINT
into a global-scope enum with better names. I also converted bools
into CaretAssociationHint in a few places where that was appropriate,
but there are still some more places (GetChildFrameContainingOffset)
where bools need to be converted. I figured this patch was big enough already.
--HG--
extra : rebase_source : cc618ef60e707e1360644340a2648de389383da0
I was inspired by the previous patch to remove FrameLayerBuilder.h from
nsDisplayList.h too.
--HG--
extra : rebase_source : b34a01bea5865da4737817e2396b98d54cc6d1bf
As the second step in dividing functionality between AnimationPlayer and
Animation, this patch moves the AnimationTiming member from AnimationPlayer to
Animation.
Most of this patch is simply moving code around. However, one significant
functional difference is that Animation::GetLocalTime() uses the mParentTime
member which is set when the Animation is updated by the player it is attached
to.
Other less significant differences are:
* AnimationPlayer::GetLocalTime is renamed to GetCurrentTimeDuration
In Web Animations, animation players have a (writeable) "current time" and
animations have a (read-only) "local time".
We would call the method simply "GetCurrentTime" (instead of
"GetCurrentTimeDuration") but GetCurrentTime is the name of the method used in
the content-facing API where it returns a double.
* "IsCurrent" is defined on both AnimationPlayer and Animation with the version
in AnimationPlayer serving mostly as a convenience shortcut to the version on
Animation.
* Animation::GetComputedTiming (previously on AnimationPlayer) now makes the
timing parameter optional since most of the time it is not needed.
As the first step in dividing the functionality currently contained in
AnimationPlayer between AnimationPlayer and Animation this patch moves the set
of keyframe properties to the Animation.
These properties are returned from the Animation by a couple of Properties()
methods that provide direct access to the member variable. In future it is
anticipated that the non-const version will be replaced with an appropriate
setter function. This will likely happen when we implement a separate
KeyframeEffect object as defined by the Web Animations API.
With regards to error checking, nsAnimationManager checks the result of
AnimationPlayer::GetSource() and handles the case where it is nullptr.
nsTransitionManager, however, simply asserts that GetSource() is never null much
like it also asserts that there is only one property with one segment in the
animation. Eventually this code should be made more generic which will probably
happen in bug 999927.
Now that we have both AnimationPlayer and Animation in use we need to clarify
which object we are referring to. This patch renames a number of member and
local variables to better reflect whether they point to an AnimationPlayer or an
Animation.
This patch is mostly renaming only with one exception. Since we are touching
a number of local variables used in loops (for looping over the array of
animation players) we take the opportunity to replace a number of instances of
uint32_t with size_t since that is the preferred type for array indices now.
This patch renames mozilla::ElementAnimations to mozilla::dom::AnimationPlayer
and moves the code from layout/style/AnimationCommon.cpp to
dom/animation/AnimationPlayer.cpp.
It also moves various helper classes needed by AnimationPlayer to
AnimationPlayer.cpp and moves them from the mozilla::css namespace to the
mozilla namespace.
Beyond that, there are no functional changes contained in this patch.
The renaming of various members and variables that used to refer to
ElementAnimation objects but now refer to AnimationPlayer objects--to give them
a more appropriate name--is performed in a subsequent patch.
--HG--
rename : layout/style/AnimationCommon.cpp => dom/animation/AnimationPlayer.cpp
rename : layout/style/AnimationCommon.h => dom/animation/AnimationPlayer.h
* * *
The current reference frame is still the same as our reference frame because we set and restore it in nsFrame::BuildDisplayListForChild before this. So we need to actually compute it.
