During metrics initialization we load a few uncached glyph widths which can occasionally
show up in a profile. This should reduce the overhead of that somewhat.
Differential Revision: https://phabricator.services.mozilla.com/D46786
--HG--
extra : moz-landing-system : lando
Fix scissor rect being incorrect during pinch zoom due to floating
point inaccuracies.
Differential Revision: https://phabricator.services.mozilla.com/D46743
--HG--
extra : moz-landing-system : lando
Cairo would normally query both the advance and other metrics at the same time,
then store them in a glyph cache sitting on each cairo_scaled_font_t any time
any of the extents were queried. Each cached scaled glyph metrics would require
about 150 bytes of space and could thus use a horribly large amount of memory
when a lot of glyphs were being used within a scaled font.
This tries to duplicate the behavior of querying and storing both advance and
bounds at the same time to effectively cut the number of glyph loads in half
for most cases. This should only add another 8 bytes per hash entry to store
the cached bounds, thus putting us way ahead on memory usage compared to what
Cairo did under the hood.
Further, Cairo would keep around cairo_scaled_font_t's in a holdover cache
even after there are no existing references to them and the owning gfxFonts
have long since died. This gives an artificial boost in successive runs of the
benchmark, while not aiding in the performance of the first run. I don't
believe the extra memory use would be justified to reproduce that particular
behavior, especially since our expectations are that the glyph cache for
a gfxFont dies when the gfxFont itself dies from the gfxFontCache.
In any case, this should at least significantly boost our glyph metrics
performance on a cold start, with the caveat about the warm start case.
Differential Revision: https://phabricator.services.mozilla.com/D46726
--HG--
extra : moz-landing-system : lando
Cairo would normally query both the advance and other metrics at the same time,
then store them in a glyph cache sitting on each cairo_scaled_font_t any time
any of the extents were queried. Each cached scaled glyph metrics would require
about 150 bytes of space and could thus use a horribly large amount of memory
when a lot of glyphs were being used within a scaled font.
This tries to duplicate the behavior of querying and storing both advance and
bounds at the same time to effectively cut the number of glyph loads in half
for most cases. This should only add another 8 bytes per hash entry to store
the cached bounds, thus putting us way ahead on memory usage compared to what
Cairo did under the hood.
Further, Cairo would keep around cairo_scaled_font_t's in a holdover cache
even after there are no existing references to them and the owning gfxFonts
have long since died. This gives an artificial boost in successive runs of the
benchmark, while not aiding in the performance of the first run. I don't
believe the extra memory use would be justified to reproduce that particular
behavior, especially since our expectations are that the glyph cache for
a gfxFont dies when the gfxFont itself dies from the gfxFontCache.
In any case, this should at least significantly boost our glyph metrics
performance on a cold start, with the caveat about the warm start case.
Differential Revision: https://phabricator.services.mozilla.com/D46726
--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
We don't need this anymore now that we're always
using the visible rect.
This requires bug 1582528 to properly set the visible area.
Differential Revision: https://phabricator.services.mozilla.com/D46628
--HG--
extra : moz-landing-system : lando
We don't need this anymore now that we're always
using the visible rect.
This requires bug 1582528 to properly set the visible area.
Differential Revision: https://phabricator.services.mozilla.com/D46628
--HG--
extra : moz-landing-system : lando
This update brings in several bugfixes and compatibility with newer
libstdc++ versions.
Differential Revision: https://phabricator.services.mozilla.com/D45860
--HG--
extra : moz-landing-system : lando
This also changes CompositorBridgeChild to create the CanvasChild lazily.
Depends on D44154
Differential Revision: https://phabricator.services.mozilla.com/D44873
--HG--
extra : moz-landing-system : lando
If VR process haven't launched yet, we couldn't get available VR displays and its states, so we need to make enumationCompleted to be false, and ask it do the enumeration again.
Differential Revision: https://phabricator.services.mozilla.com/D46238
--HG--
extra : moz-landing-system : lando
Preparation work for adding DirectComposition support. It does not add a new functionality.
Differential Revision: https://phabricator.services.mozilla.com/D46429
--HG--
extra : moz-landing-system : lando
We only use the png codec so let's save some link time by not including
the other codecs.
Differential Revision: https://phabricator.services.mozilla.com/D46317
--HG--
extra : moz-landing-system : lando
Previously, the setup_picture_caching function was hard coded
to support only a very specific shape of display list. With this
change, flags are added to PrimitiveCluster that can specify
if a picture cache slice should be created before / after this
cluster when picture caching is set up.
The usage of these flags in this patch matches the old behaviour,
so should not have any functional effect.
However, in future we will make use of this functionality to
create picture slices for a number of different use cases, such as:
* Creating cache tiles for the UI.
* Slicing the scene where there are video elements, in order to
allow these to be composited directly by the OS. This may also
apply to WebGL and/or canvas elements.
* Slicing the scene when there is a very large fixed position
background image or other element, to avoid invalidating the
entire tile cache each frame.
Differential Revision: https://phabricator.services.mozilla.com/D46125
--HG--
extra : moz-landing-system : lando
IDCompositionDevice::Commit needs to be called when there is an update to DirectComposition. RenderCompositorANGLE updates DirectComposition only during initialization. Then it is not necessary to call the function in EndFrame().
Differential Revision: https://phabricator.services.mozilla.com/D46249
--HG--
extra : moz-landing-system : lando
This fixes a case where the is_same_content field was no longer
being reset to true before dependency calculation could occur.
In some cases, this could result in a tile being updated, but
the dirty rect being empty, which meant all primitives in that
tile would fail the visibility culling test.
Differential Revision: https://phabricator.services.mozilla.com/D46247
--HG--
extra : moz-landing-system : lando
This patch replaces the is_backface_visible bool in the common
per-primitive data in the display list with a PrimitiveFlags
enumeration. This will allow Gecko to specify extra information
about certain primitive, such as tagging scroll bars.
Differential Revision: https://phabricator.services.mozilla.com/D45970
--HG--
extra : moz-landing-system : lando
This provides the internal device-space dirty rects calculated
during picture cache updates to the external render() method.
This allows clients to provide these to OS partial present APIs,
to reduce power usage and improve performance.
In this initial implementation, if a scroll or scale of the main
picture cache has occurred, the dirty rect will be the entire
screen. This should ensure correctness. In future, we can handle
this case by supplying the picture cache transforms to the OS
compositor integration.
However, the dirty rects will be valid for any non-scroll cases,
such as animations or video playback. This should result in some
significant power savings and performance improvements for these
use cases.
Differential Revision: https://phabricator.services.mozilla.com/D46082
--HG--
extra : moz-landing-system : lando
This patch replaces the is_backface_visible bool in the common
per-primitive data in the display list with a PrimitiveFlags
enumeration. This will allow Gecko to specify extra information
about certain primitive, such as tagging scroll bars.
Differential Revision: https://phabricator.services.mozilla.com/D45970
--HG--
extra : moz-landing-system : lando
In places where profiler_is_active() was used around a profiler_add_marker() (or
similar) call, replace it with profiler_can_accept_markers().
Differential Revision: https://phabricator.services.mozilla.com/D44435
--HG--
extra : moz-landing-system : lando
Payloads will serialize themselves into a `BlocksRingBuffer` entry when first
captured.
Later they will be deserialized, to stream JSON for the output profile.
Differential Revision: https://phabricator.services.mozilla.com/D43428
--HG--
extra : moz-landing-system : lando
This works by keeping track of the previous visible rect and
computing a preserved rect by intersecting with the new visible
rect.
We force the dirty rect to be inside this preserved area.
Differential Revision: https://phabricator.services.mozilla.com/D45284
--HG--
extra : moz-landing-system : lando
Previously after RecvResumeAndResize() we would set a flag on the root
WebRenderBridgeParent, which in turn sets a flag on the next display list it
receives that it should be treated as a first paint. Then when that display list
is finally composited, we call UiCompositorControllerParent::NotifyFirstPaint(),
which in turn tells GeckoView to uncover the widget.
After switching tabs in GeckoView browsers, however, the root
WebRenderBridgeParent does not always receive a new display list, so the widget
would not be uncovered. Instead of waiting for the next received display list to
be composited, we simply want to uncover the widget on the next composite. To
achieve this we instead set the forced-first-paint flag on the root
CompositorBridgeParent then we call NotifyFirstPaint() during
CompositorBridgeParent::NotifyPipelineRendered().
Differential Revision: https://phabricator.services.mozilla.com/D46157
--HG--
extra : moz-landing-system : lando
We compute the preserved bounds for each item and see if it's
contained in the invalid area. The gecko side will do the same
computation.
Appologies for duplicating euclid with Box2d type. We can deal with
that in a followup.
The asserts are disabled for now. I tried reenabling them and they
triggered. I haven't had a chance to figure out if they are still
valid.
Differential Revision: https://phabricator.services.mozilla.com/D45283
--HG--
extra : moz-landing-system : lando
Lee Salzman
Glenn Watson
Daniel Varga
Jonathan Kew
Cosmin Sabou
Andrew Osmond
Jeff Muizelaar
Oana Pop Rus
Nathan Froyd
Bob Owen
Daosheng Mu
sotaro
Botond Ballo
Dzmitry Malyshau
Henri Sivonen
A. Wilcox
Andreea Pavel
Gerald Squelart
Jeff Muizelaar
Jamie Nicol
Dustin J. Mitchell
Nicolas Silva