These definitions are implicitly created now, but trunk clang considers
implicit creation to be a bug when you have explicitly declared copy
constructors.
Differential Revision: https://phabricator.services.mozilla.com/D56970
--HG--
extra : moz-landing-system : lando
This also optimizes the surface returned by CreateSourceSurfaceFromData to
match what would happen in the non-recorded case. This means that all surfaces
of type RECORDING are optimized, i.e. they represent a surface type that
matches the DrawTarget type in the Translator.
Differential Revision: https://phabricator.services.mozilla.com/D55292
--HG--
extra : moz-landing-system : lando
This is instead of using the reference DrawTarget to create it, because that
will sometimes fail for large surfaces.
Differential Revision: https://phabricator.services.mozilla.com/D55148
--HG--
extra : moz-landing-system : lando
Now that we have C++17, and thus inline const, we can do this.
Depends on D56306
Differential Revision: https://phabricator.services.mozilla.com/D56307
--HG--
extra : moz-landing-system : lando
These new methods will be automatically used by ARM targets for image
decoding. Specifically it should reduce the time required to decode GIFs
and opaque PNGs.
Differential Revision: https://phabricator.services.mozilla.com/D56030
--HG--
extra : moz-landing-system : lando
Using Rect() will work properly when mDrawTarget does not have 0,0
origin. It also makes the code's intention more clear.
Differential Revision: https://phabricator.services.mozilla.com/D55337
--HG--
extra : moz-landing-system : lando
Using Rect() will work properly when mDrawTarget does not have 0,0
origin. It also makes the code's intention more clear.
Differential Revision: https://phabricator.services.mozilla.com/D55337
--HG--
extra : moz-landing-system : lando
OS_RGBA and OS_RGBX are defined as the preferred surface format for the
platform and architecture, fixed at compile time. Today this will be
initially defined as B8G8R8A8. The future intent is that once all parts
of the system support all configurations, then we can use R8G8B8A8 on
certain platforms (e.g. Android, Linux, Mac) and invert it on big-endian
architectures.
Differential Revision: https://phabricator.services.mozilla.com/D52006
--HG--
extra : moz-landing-system : lando
This also removes the DrawEventRecorderPrivate::IsEmpty method as it is no
longer used. It doesn't undo the splitting out of the tracking of the
UnscaledFonts, which was added at the same time, because I think it is useful
to highlight the fact that they are never currently removed.
Differential Revision: https://phabricator.services.mozilla.com/D51593
--HG--
extra : moz-landing-system : lando
This also includes the implementation of SetAnimatable, FromAnimatable,
and merge the final matrix with motion path.
Besides, we always use PathBuilderSkia for calculating the gfx::Path for
web-renderer.
Differential Revision: https://phabricator.services.mozilla.com/D50011
--HG--
extra : moz-landing-system : lando
The recorder can still contain UnscaledFonts, but they are never removed
currently, so we can't wait for them and they will be re-recorded safely anyway.
Depends on D49757
Differential Revision: https://phabricator.services.mozilla.com/D49758
--HG--
extra : moz-landing-system : lando
Please note that it is the first reformat with clang-format 9
I only saw a fix in the .mm file
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D49056
--HG--
extra : moz-landing-system : lando
This was added as part of an intermediate step to blob
recoordination. It's not used anymore.
Differential Revision: https://phabricator.services.mozilla.com/D47354
--HG--
extra : moz-landing-system : lando
This was added as part of an intermediate step to blob
recoordination. It's not used anymore.
Differential Revision: https://phabricator.services.mozilla.com/D47354
--HG--
extra : moz-landing-system : lando
These variants perform significantly faster than the C implementations
according to local testing and that in treeherder. Image decoding is as
much as 40% faster in the most simple cases (solid green PNG image).
Differential Revision: https://phabricator.services.mozilla.com/D46446
--HG--
extra : moz-landing-system : lando
Some image decoders (e.g. PNG) may have a native representation of the
data as RGB, and do not have accelerated methods to transform from RGB
to RGBX/BGRX. Exposing this as part of the swizzle/premultiply methods
allows us to write accelerated versions ourselves in a later patch in
this series.
Differential Revision: https://phabricator.services.mozilla.com/D46445
--HG--
extra : moz-landing-system : lando
The image decoders produce surfaces row by row, so a variant to get a
function pointer to perform swizzle/premultiply operations makes more
ergonomic sense.
Differential Revision: https://phabricator.services.mozilla.com/D46444
--HG--
extra : moz-landing-system : lando
This removes a lot of old cruft in thebes to instantiate Cairo scaled fonts.
Instead, we only instantiate the Cairo scaled font inside Moz2D when we actually
need it for DrawTargetCairo. This thus gets rid of the duplicated code we had
inside both Moz2D and thebes to deal with Cairo scaled fonts.
Differential Revision: https://phabricator.services.mozilla.com/D47297
--HG--
extra : moz-landing-system : lando
These variants perform significantly faster than the C implementations
according to local testing and that in treeherder. Image decoding is as
much as 40% faster in the most simple cases (solid green PNG image).
Differential Revision: https://phabricator.services.mozilla.com/D46446
--HG--
extra : moz-landing-system : lando
Some image decoders (e.g. PNG) may have a native representation of the
data as RGB, and do not have accelerated methods to transform from RGB
to RGBX/BGRX. Exposing this as part of the swizzle/premultiply methods
allows us to write accelerated versions ourselves in a later patch in
this series.
Differential Revision: https://phabricator.services.mozilla.com/D46445
--HG--
extra : moz-landing-system : lando
The image decoders produce surfaces row by row, so a variant to get a
function pointer to perform swizzle/premultiply operations makes more
ergonomic sense.
Differential Revision: https://phabricator.services.mozilla.com/D46444
--HG--
extra : moz-landing-system : lando
These variants perform significantly faster than the C implementations
according to local testing and that in treeherder. Image decoding is as
much as 40% faster in the most simple cases (solid green PNG image).
Differential Revision: https://phabricator.services.mozilla.com/D46446
--HG--
extra : moz-landing-system : lando
Some image decoders (e.g. PNG) may have a native representation of the
data as RGB, and do not have accelerated methods to transform from RGB
to RGBX/BGRX. Exposing this as part of the swizzle/premultiply methods
allows us to write accelerated versions ourselves in a later patch in
this series.
Differential Revision: https://phabricator.services.mozilla.com/D46445
--HG--
extra : moz-landing-system : lando
The image decoders produce surfaces row by row, so a variant to get a
function pointer to perform swizzle/premultiply operations makes more
ergonomic sense.
Differential Revision: https://phabricator.services.mozilla.com/D46444
--HG--
extra : moz-landing-system : lando
These variants perform significantly faster than the C implementations
according to local testing and that in treeherder. Image decoding is as
much as 40% faster in the most simple cases (solid green PNG image).
Differential Revision: https://phabricator.services.mozilla.com/D46446
--HG--
extra : moz-landing-system : lando
Some image decoders (e.g. PNG) may have a native representation of the
data as RGB, and do not have accelerated methods to transform from RGB
to RGBX/BGRX. Exposing this as part of the swizzle/premultiply methods
allows us to write accelerated versions ourselves in a later patch in
this series.
Differential Revision: https://phabricator.services.mozilla.com/D46445
--HG--
extra : moz-landing-system : lando
The image decoders produce surfaces row by row, so a variant to get a
function pointer to perform swizzle/premultiply operations makes more
ergonomic sense.
Differential Revision: https://phabricator.services.mozilla.com/D46444
--HG--
extra : moz-landing-system : lando
This fixes a bug that was introduced three years ago in bug 1268854.
What happened was that the final pass over the polygon assumed that the current
polygon was living in plane[0]. But due to the double buffering, the "current"
polygon alternates between plane[0] and plane[1]. And bug 1268854 had introduced
an early exit so that we could hit the final pass at a time where the current,
now empty, polygon was in plane[1]. So we would incorrectly treat all 32 points
in plane[0] as part of the final polygon.
This bug was responsible for intermittently unreasonable numbers in CompositorOGL's fill
rate / overdraw overlay, and, since changeset cc84a0e9d5ddde198422f4f11ab6bf85f631d5f0,
also caused CompositorOGL to execute unnecessary draw calls.
Differential Revision: https://phabricator.services.mozilla.com/D44312
--HG--
extra : moz-landing-system : lando
This also fixes DrawTargetSkia::CanCreateSimilarDrawTarget because currently
if only one of the height or width is negative then it doesn't get caught.
Differential Revision: https://phabricator.services.mozilla.com/D43075
--HG--
extra : moz-landing-system : lando
These functions were made public in 10.6. The oldest version we support is 10.9.
Differential Revision: https://phabricator.services.mozilla.com/D41813
--HG--
extra : moz-landing-system : lando
These were used for creating accelerated CGContexts that render to an IOSurface.
We only used those experimentally on Nightly for a while but turned that option
off because of crashes. And in the meantime, DrawTargetCG has been removed
entirely. So we'll probably never use these functions again.
Differential Revision: https://phabricator.services.mozilla.com/D41809
--HG--
extra : moz-landing-system : lando
ScaledFontFreeType::GetWRFontInstanceOptions() was neglecting to set
the FontInstanceFlags::EMBEDDED_BITMAPS flag. This was causing us to
always take the non-bitmap path when rasterizing the glyph, which
fails on android because emoji fonts are bitmap only. Setting this
flag causes glyphs to be rendered correctly on android webrender.
Differential Revision: https://phabricator.services.mozilla.com/D40062
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
`sGfxLogLevel` is a global variable whose value mirrors the value of the
"gfx.logging.level" pref in the prefs table, and is kept up to date by a
prefs callback.
But "gfx.logging.level" is a static pref that already has a mirror variable,
accessible via `StaticPrefs::gfx_logging_level()`.
So we can use the latter and remove the former, and this patch does that. The
patch also removes a sentence in a comment that refers to special treatment of
LOG_DEBUG and LOG_DEBUG_PRLOG, because that sentence appears to be referring to
something (another comment?) that is no longer present.
Differential Revision: https://phabricator.services.mozilla.com/D35625
--HG--
extra : moz-landing-system : lando
Currently it's completely unclear at use sites that the getters for `once`
static prefs return the pref value from startup, rather than the current pref
value. (Bugs have been caused by this.) This commit improves things by changing
the getter name to make it clear that the pref value obtained is from startup.
This required changing things within libpref so it distinguishes between the
"base id" (`foo_bar`) and the "full id" (`foo_bar` or
`foo_bar_DoNotUseDirectly` or `foo_bar_AtStartup` or
`foo_bar_AtStartup_DoNotUseDirectly`; the name used depends on the `mirror` and
`do_not_use_directly` values in the YAML definition.) The "full id" is used in
most places, while the "base id" is used for the `GetPrefName_*` and
`GetPrefDefault_*` functions.
(This is a nice demonstration of the benefits of the YAML file, BTW. Making
this change with the old code would have involved adding an entry to every
single pref in StaticPrefList.h.)
The patch also rejigs the comment at the top of StaticPrefList.yaml, to clarify
some things.
Differential Revision: https://phabricator.services.mozilla.com/D38604
--HG--
extra : moz-landing-system : lando
Alex Henrie
Oana Pop Rus
Jonathan Kew
Matt Woodrow
Jeff Walden
Nathan Froyd
Bob Owen
Emilio Cobos Álvarez
Andrew Osmond
Jeff Muizelaar
James Hooks
Lee Salzman
Boris Chiou
Sylvestre Ledru
Botond Ballo
Markus Stange
Daniel Varga
Cosmin Sabou
Kris Taeleman
Eric Rahm
Mike Hommey
Jamie Nicol
Jean-Yves Avenard
Narcis Beleuzu
Nicholas Nethercote