On windows it's possible for us to fallback from D2D to Skia rendering at any time due to a device reset.
If this happens with `enable-tiles-if-skia-pomtp` enabled we could begin to use tiling. This can cause a
crash if we never created the worker threads because at initialization time we weren't using tiling.
Another way to fix this would be to dynamically create the worker threads in UpdateRenderMode if we
have switched to skia. That's a larger change and more might be required, so I'd rather just fix the
crash for now.
This commit also fixes a pref that should be `Once` instead of `Live`.
MozReview-Commit-ID: JQidXPjI7ER
--HG--
extra : amend_source : ba9a3746faea3a7355251b7e97e3f7c5dc1ba06b
This rearranges how synthetic-bold use is determined in the font selection
& rendering code. Previously, we would decide during the font-selection
algorithm whether we need to apply synthetic-bold to the chosen face, and
then pass that decision through the fontgroup (storing it in the FamilyFace
entries of the mFonts array there) down to the actual rendering code that
instantiates fonts from the faces (font entries) we've selected.
That became a problem for variation fonts because in the case of a user
font, we may not have downloaded the resource yet, so we just have a "user
font container" entry, which carries the descriptors from the @font-face
rule and will fetch the actual resource when needed. But in the case of a
@font-face rule without a weight descriptor, we don't actually know at
font-selection time whether the face will support "true" bold (via a
variation axis) or not, so we can't reliably make the right decision about
applying synthetic bold.
So we now defer that decision until we actually instantiate a platform font
object to shape/measure/draw text. At that point, we have the requested
style and we also have the real font resource, so we can easily determine
whether fake-bold is required.
(This patch should not result in any visible behavior change; that will
come in a second patch now that the architecture supports it.)
With async scene building, we might get the message to delete certain
compositor animation ids while we are still building and rendering
scenes that have those compositor animations. This patch associates
those ids with the epoch at which they are safe to delete, and only does
the deletion once we have rendered that epoch.
MozReview-Commit-ID: Jetfcdtwt1q
--HG--
extra : rebase_source : f06b8ee62e460432e8faed670e928f60cb6bc915
This also rearranges the method implementation slightly to make the next
patch easier to read. This patch should have zero functional changes,
it's just refactoring.
MozReview-Commit-ID: 53StJ0TH3IT
--HG--
extra : rebase_source : 2f3aeb54271da75a7e051afc24b8a4c96f8496f2
Before this change, the value which was set by SetShadowBaseTransform()
has been used for the assertion, but it is possible that the value is changed
by APZ. And it's hard to tell whether the value has been changed by APZ or not
and it's hard to *reverse-calculate* the differences in the past APZ at the
moment we want to do the assert.
So after this patch, on debug build we don't actually skip the calculation for
unchanged animations and use the newly calculated value for the assertion.
MozReview-Commit-ID: 8fCcvvbUMHe
--HG--
extra : rebase_source : 0ff5e7100ad33a690bb0edd02af2b00c749afbbe
The FlingPhysics controls the shape of the fling curve, including how fast
and far it goes, while leaving other logic (related to flywheel, handoff,
overscroll, etc.) centralized in GenericFlingAnimation.
FlingPhysics is a template parameter of GenericFlingAnimation because we
already have a dynamic dispatch on the type of the animation, we don't
need another one for the physics.
I called the specific class implementing the current physics
DesktopFlingPhysics because since the deprecation of B2G and Android
switching to StackScrollerFlingAnimation, it's only used in desktop touch
scenarios.
MozReview-Commit-ID: LhJ9rpPrnXC
--HG--
extra : rebase_source : e53f1d7bbe3e0a588f5d5ba530c59e03cdc50d69
extra : source : 8fda27f6bbf30cc14966c80780c9e09533e7b7e5
The calculation in that function is specific to a particular physics model,
so it's inappropriate to house it in Axis.
Also do some light refactoring to this function, to make modifying the
velocity the caller's responsibility (this becomes relevant in the next
patch, where we factor out the physics logic into a class that can't
modify the APZC).
MozReview-Commit-ID: 5ALQd3LBx3O
--HG--
extra : rebase_source : 2290b72d3026878b34c86f437b0fac093d9fceac
Ryan Hunt
Botond Ballo
Gurzau Raul
Kartikaya Gupta
Cosmin Sabou
Jonathan Kew
Andreea Pavel
Hiroyuki Ikezoe
Andrew Osmond
Csoregi Natalia
Bas Schouten
Lee Salzman