Previously, we would do a fine-grained visibility check for
prims against the dirty rect stack (after coarse grained
tile visibility), then prepare the primitive, then determine
which command buffer(s) the prim should be added to, based
on which tile(s) the prim affects.
The patch changes this so that the fine-grained visibility
check returns a list of command buffer(s) that the prim
should be added to. This is passed to the prim prepare
step, and then used to directly add prims to the buffers
rather than checking which tiles are affected by the prim.
The motivation for doing this will become apparent in
follow up patches. We want to be able to encode
multiple command buffer commands per-prim, whereas it
was previously only possible to encode primitive
commands. By allowing prim-prepare to write directly
to the command buffers, rather than return a list of
primitive commands, we can write whatever commands
are needed. Future patches will use this to write
segment rect streams, and other information.
A side effect of this is that the `tile_rect` field
in the `PrimitiveVisibility` struct is no longer
required. This reduces the size of `PrimitiveInstance`
from 104 bytes to 88 bytes, which is likely to be
a reasonable performance win on pages that have
high primitive counts.
Differential Revision: https://phabricator.services.mozilla.com/D172081
In the patches for bug 1823215, we eliminated the use of a local copy of the glyph runs array
during SortGlyphRuns; but we call RemoveElementAt individually for each run to be coalesced,
which means potentially moving all the rest of the array multiple times. Instrumentation shows
that we sometimes end up with dozens of glyphruns to be coalesced (or even hundreds/thousands,
in pathological cases), which becomes quite inefficient.
Using RemoveElementsBy(predicate) instead will minimize the copying/moving of the remaining
array elements.
Differential Revision: https://phabricator.services.mozilla.com/D172945
The math for directly calculating the endpoint of the arc is actually trivial,
and ArcToBezier is pretty expensive so should be avoided.
Differential Revision: https://phabricator.services.mozilla.com/D172929
While Firefox builds for Android ARMv7 don't support non-NEON
processors, downstreams (including non-Android ones) may still want to
support them.
On the Firefox builds that don't support non-NEON processors, the NEON
flags are actually already passed globally, and they don't need to be
explicitly added. NEON_FLAGS is actually only meant to be used for
sources that specifically need NEON support even when the target doesn't
support it, for, e.g. specialized code behind runtime CPU detection.
So removing NEON_FLAGS is a no-op in practice when NEON processors are
already targeted.
Differential Revision: https://phabricator.services.mozilla.com/D172801
Destroy RenderBufferTextureHosts that use VideoBridgeParent's Shmems before destroying all VideoBridgeParent's Shmems by PVideoBridgeParent::OnChannelError().
Differential Revision: https://phabricator.services.mozilla.com/D169796
Make use of the new changes in the cssparser that allows 'none' keywords
in color components where allowed. We store the none values as 0.0 (as
per the spec) and mark the components with the flags. This way we don't
have to check anything on the components before doing calculations.
As this is the last part intended to be released for the new [color-4]
changes, I've also enabled the changes on nightly.
Differential Revision: https://phabricator.services.mozilla.com/D170208
Make use of the new changes in the cssparser that allows 'none' keywords
in color components where allowed. We store the none values as 0.0 (as
per the spec) and mark the components with the flags. This way we don't
have to check anything on the components before doing calculations.
As this is the last part intended to be released for the new [color-4]
changes, I've also enabled the changes on nightly.
Differential Revision: https://phabricator.services.mozilla.com/D170208
Previously, we would do a fine-grained visibility check for
prims against the dirty rect stack (after coarse grained
tile visibility), then prepare the primitive, then determine
which command buffer(s) the prim should be added to, based
on which tile(s) the prim affects.
The patch changes this so that the fine-grained visibility
check returns a list of command buffer(s) that the prim
should be added to. This is passed to the prim prepare
step, and then used to directly add prims to the buffers
rather than checking which tiles are affected by the prim.
The motivation for doing this will become apparent in
follow up patches. We want to be able to encode
multiple command buffer commands per-prim, whereas it
was previously only possible to encode primitive
commands. By allowing prim-prepare to write directly
to the command buffers, rather than return a list of
primitive commands, we can write whatever commands
are needed. Future patches will use this to write
segment rect streams, and other information.
A side effect of this is that the `tile_rect` field
in the `PrimitiveVisibility` struct is no longer
required. This reduces the size of `PrimitiveInstance`
from 104 bytes to 88 bytes, which is likely to be
a reasonable performance win on pages that have
high primitive counts.
Differential Revision: https://phabricator.services.mozilla.com/D172081
The `mHandledResult` is set in the ctor of APZEventResult based on an incoming
TargetConfirmationFlags, we shouldn't clobber the original `mHandledResult` when
we set `eConsumeDoDefault` for pan events.
Note that we should probably do the same thing for other
SetStatusAsConsumeDoDefault call sites basically, but for now I'd like to make
this change as mimumum as possible.
Differential Revision: https://phabricator.services.mozilla.com/D172525
This combines the multiple fields or variants which were previously used to
track sided types like protocol types into a single field wrapped with a
SideVariant.
This will be used in the next part to avoid the need for default constructors
for actor types allowing the proper types to be used.
Differential Revision: https://phabricator.services.mozilla.com/D168879
Mingw's dcomp.h is not the official one, but rather a by-hand
reproduction. While this newly-updated version has e.g.
IDCompositionFilterEffect, it is still missing e.g.
IDCompositionColorMatrixEffect.
Differential Revision: https://phabricator.services.mozilla.com/D168839
+ Add gfx.color_management.rec709_gamma_as_srgb:true. :'(
In particular, rec709(16/255) -> srgb(31/255). Even though it's
technically correct, it's practically-speaking incorrect, since that's
not what Chrome does, nor what the web expected for years and years.
In practice, basically everyone expects gamma to just be completely
ignored.
What people expect:
* Pretend gamut is srgb(==rec709), but stretch this naively for the
display. If you have a display-p3-gamut display, srgb:0.5 expects to
be displayed as display:0.5, which will be display-p3:0.5 to the eyes.
* Pretend all content gammas (TFs) are srgb(!=rec790), and then bitcast this
naively for the display. E.g. rec709(16/255) should
display the same as srgb(16/255), not srgb(31/255). (Note: display-p3
uses srgb gamma) But if your display has e.g. gamma=3.0, don't
convert or compensate.
This is a formalization of what you get when you spend decades ignoring
color management, and people build things based on behavior-in-practice,
not behavior-in-theory.
Also:
+ gfx.color_management.native_srgb:true for Windows, so we don't use the
display color profile, which no one else does.
+ Add rec2020_gamma_as_rec709, so we have a path towards maybe having
rec2020 use its correct transfer function, rather than srgb (like
rec709).
Differential Revision: https://phabricator.services.mozilla.com/D161857
Glenn Watson
Jonathan Kew
Lee Salzman
Emanuele Rocca
sotaro
Kelsey Gilbert
Norisz Fay
pmcmanis
Tiaan Louw
Marian-Vasile Laza
Cosmin Sabou
Ryan VanderMeulen
Hiroyuki Ikezoe
Iulian Moraru
Nika Layzell
Andi-Bogdan Postelnicu
Chris Martin
Botond Ballo
Otto Länd
Butkovits Atila
Robert Longson