Adds another restyle generation which represents the dirty state of raw
style changes, so that getComputedStyle() wont be confused by optimizations
made by style engines.
MozReview-Commit-ID: 7RYeNCzFygO
The difference is that PostRestyleEventForCSSRuleChanges sets
mRestyleForCSSRuleChanges true. In a subsequent patch,
we propagate a new TraversalRestyleBehavior flag to servo side
if mRestyleForCSSRuleChanges is true.
MozReview-Commit-ID: IKsBbm09uT9
We need to request an animation-only restyle to force flush all throttled
animations on main thread when we handle an event with coordinates
(e.g. mouse event).
MozReview-Commit-ID: KkjeQVsLgTl
Some changes to animations don't affect the computed style and yet still
require the layer to be updated. Therefore, we also need to call
AddLayerChangesForAnimation in ServoRestyleManager. In this patch, we
factor out this function from GeckoRestyleManager, so we can reuse it.
MozReview-Commit-ID: LL7D1oGS65l
The main renaming was generated with the following python script:
```
import sys
import re
CAMEL_CASE_REGEX = re.compile(r"(^|_|-)([A-Z])([A-Z]+)")
DISPLAY_REGEX = re.compile(r"\bNS_STYLE_DISPLAY_([^M][A-Z_]+)\b")
def to_camel_case(ident):
return re.sub(CAMEL_CASE_REGEX,
lambda m: m.group(2) + m.group(3).lower(), ident)
def constant_to_enum(constant):
return "StyleDisplay::" + to_camel_case(constant) + ("_" if constant == "NONE" else "")
def process_line(line):
return re.sub(DISPLAY_REGEX,
lambda m: constant_to_enum(m.group(1)), line)
lines = []
with open(sys.argv[1], "r") as f:
for line in f:
lines.append(process_line(line))
with open(sys.argv[1], "w") as f:
for line in lines:
f.write(line)
```
And the following shell commands:
```
find . -name '*.cpp' -exec python display.py {} \;
find . -name '*.h' -exec python display.py {} \;
```
MozReview-Commit-ID: 91xYCbLC2Vf
The existing static_cast checks are totally wrong, by the way, since
nsIDocuments are never nsIContent. Looks like they were erroneously
added in bug 862763.
After explicitly define default value for RestyleResult, we have a value
starting from 0 now. So, we can drop the explicity numbering.
MozReview-Commit-ID: 1UlpkUT6mAL
We also want to cancel transitions with destroyed frames, so the simplest way
is to extend the ability of AnimationsWithDestroyFrame to cancel transitions as
well.
While processing restyles and starting transitions, we may trigger
a call to EffectCompositor::UpdateCascadeResults which may, in turn, call
EffectCompositor::RequestRestyle with RestyleType::Layer, which ultimately
results in a call to RestyleManager::IncrementAnimationGeneration().
Typically, nsTransitionManager::StyleContextChanged compares the animation
generation on its collection with that of the restyle manager and uses this
to ignore the restyle that it generates. However, given the sequence of events
above, that check may no longer help since the restyle manager's animation
generation will be out of step. As a result,
nsTransitionManager::StyleContextChanged will fail to ignore a subsequent
and redundant restyle. With certain combinations of content, this can mean that
restyles are posted in such a manner than an infinite cycle of restyles ensues.
This patch causes RestyleManager to ignore calls to IncrementAnimationGeneration
when it is already processing restyles such that the animation generation is
only ever updated once per restyle. This makes the check for a matching
animation generation in nsTransitionManager::StyleContextChanged work as
expected, preventing us from generating needless transitions which can produce
this endless loop.
MozReview-Commit-ID: 9HYDrknKPAI
RestyleManager currently has a piece of state for tracking if throttled
animations are up-to-date or not. Actually, it's not so much about throttled
animations but really about outstanding changes to animation styles (which
is typically expected to be due to throttling animations but there are
other cases that invalidate the animation style rule that we should be
considering here).
We now have that same information stored in the EffectCompositor so we can
remove the redundant state from RestyleManager. Furthermore, the state stored
in EffectCompositor is more accurate since it captures the case when animation
style needs to be updated twice within a tick, or when nothing needs to be
updated within a tick.
This patch, therefore, introduces EffectCompositor::HasPendingStyleUpdates in
place of setting RestyleManager::mLastUpdateForThrottledAnimations.
nsTransitionManager also uses mLastUpdateForThrottledAnimations to warn if we
have not processed throttled animations. We can't use HasPendingStyleUpdates
here however, since it will return true in the case where we have triggered new
transitions in the process of restyling. However, any new transitions will
trigger "standard" (i.e. not throttled) restyles so we introduce another
method, HasThrottledStyleUpdates, that returns true only if we have outstanding
throttled updates and use this for the warning inside nsTransitionManager.
