This patch adds a new tolerance pref, which controls how far the second touchdown
is allowed to be from the first touchdown when detecting a multi-tap gesture
such as double-tap or one-touch-pinch. This stops the one-touch-pinch code
from inadvertently triggering when the user does a tap followed by a second tap
far away from the first.
The default value for the new pref is 5x the touch-start tolerance pref. This
seems to provide a reasonable behaviour for me, although this value could
probably be tuned.
MozReview-Commit-ID: 63aAyGCbvoN
--HG--
extra : rebase_source : 36e9bd66d165c8d746ea7b5d6c33e9cf2771194a
Recording mask clips in the clip stack changes the value of TopmostClipId()
which confuses the code in ScrollingLayersHelper. The mask clip can be
thought of as an "out-of-band" clip that ScrollingLayersHelper doesn't
need to know about. This patch adds a mechanism for pushing such
"out-of-band" clips without touching the clip stack.
MozReview-Commit-ID: 8Zeqtigk0cj
--HG--
extra : rebase_source : 35176f3c9d98d186f78d7a0ff44845c7c3c9f67e
This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget
hack. The old design had several limitations:
* It couldn't handle shadows
* It couldn't handle selections
* It couldn't handle font/color changes in a single text-run
* It couldn't handle decorations (underline, overline, line-through)
Mostly this was a consequence of the fact that it only modified the start and end
of the rendering algorithm, and therefore couldn't distinguish draw calls for different
parts of the text.
This new design is based on a similar principle as DrawTargetCapture, but also passes
down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can
notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us
directly pass data to TextDrawTarget when possible (as is done for shadows and selections).
In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle
changes in font/color mid-text-run (which can happen because of font fallback).
The end result is:
* We handle all shadows natively
* We handle all selections natively
* We handle all decorations natively
* We handle font/color changes in a single text-run
* Although we still hackily intercept draw calls
* But we don't need to buffer commands, reducing total memcopies
In addition, this change integrates webrender's PushTextShadow and PushLine APIs,
which were designed for this use case. This is only done in the layerless path;
WebrenderTextLayer continues to be semantically limited, as we aren't actively
maintaining non-layers-free webrender anymore.
This also doesn't modify TextLayers, to minimize churn. In theory they can be
augmented to support the richer semantics that TextDrawTarget has, but there's
little motivation since the API is largely unused with this change.
MozReview-Commit-ID: 4IjTsSW335h
--HG--
extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
This patch takes the existing code (which allows recursively pushing the necessary
part of a clip chain) and folds it into another recursive function that
operates on the ASR chain. Now the ASR recursion is the primary one, and
clips are pushed for each ASR as needed.
This code was partly modelled after the code in
ContainerState::SetupScrollingMetadata, which also iterates over the
ASRs and clips.
MozReview-Commit-ID: 1qaFPY7Ja7
--HG--
extra : rebase_source : 623b116c293e86d063e5acfa4a01f5104719f560
Note that when PushClipAndScrollInfo is called, we are pushing an
already-defined scrolling clip onto the stack, and anything that gets
pushed inside it is going to be defined as being inside that scrolling
clip. So we need to make sure to update the scroll id stack for those
calls as well. This was an oversight previously but it never mattered.
MozReview-Commit-ID: D40Gk00HYrq
--HG--
extra : rebase_source : 677a92f918481a73877f551b9ac32975e0110be9
This allows us to keep a single stack where we track both clip ids and
scroll ids with the correct interleaving order that they were pushed in.
MozReview-Commit-ID: DHHfR8JnnBw
--HG--
extra : rebase_source : f2f80e89a400d5b9982d138b29e534701b247072
We need to ensure the compositor thread is released but we cannot upon
freeing CompositorManagerParent to do that. This is because it needs to
live longer than the thread so that shared memory allocated with this
top level protocol can be freed after the fact. As such, just release
the thread reference after IPDL has released CompositorManagerParent.
A basic sanity check here seems to produce the correct behaviour but I'm
not at all confident that this will always do the correct thing in more
complex cases or when perspectives are involved. However this is hard to
test and get working without the testing infrastructure up and running
so I'd rather land this simple code first and then dig into the more
complex cases once we have a way to catch regressions.
MozReview-Commit-ID: E4HytiZowEn
--HG--
extra : rebase_source : c7466092298aebf66926e8e0bdf58eb4651f0f19
This patch takes the existing code (which allows recursively pushing the necessary
part of a clip chain) and folds it into another recursive function that
operates on the ASR chain. Now the ASR recursion is the primary one, and
clips are pushed for each ASR as needed.
This code was partly modelled after the code in
ContainerState::SetupScrollingMetadata, which also iterates over the
ASRs and clips.
MozReview-Commit-ID: 1qaFPY7Ja7
--HG--
extra : rebase_source : 0c1879531e77998254d2ccaf87479154b179545a
Note that when PushClipAndScrollInfo is called, we are pushing an
already-defined scrolling clip onto the stack, and anything that gets
pushed inside it is going to be defined as being inside that scrolling
clip. So we need to make sure to update the scroll id stack for those
calls as well. This was an oversight previously but it never mattered.
MozReview-Commit-ID: D40Gk00HYrq
--HG--
extra : rebase_source : beee11f8694489183dbeb4edcd95d89f55656486
This allows us to keep a single stack where we track both clip ids and
scroll ids with the correct interleaving order that they were pushed in.
MozReview-Commit-ID: DHHfR8JnnBw
--HG--
extra : rebase_source : 1eff7698ecc724b5457bdf67a6c4a70605038184
Add DoWithEvent which switches over an event type, reads the event into
a stack variable and calls a callable with that event as a parameter.
This avoids doing a heap allocation for every event that we play back.