We do some initialization of gfxFontSrcURI and gfxFontFaceSrc that is
main thread only on the DOM worker threads. These portions of the
initialization can easily be deferred to on demand access since they are
only ever used on the main thread itself.
Differential Revision: https://phabricator.services.mozilla.com/D153461
On Android we previously added a rendering path using the
SurfaceControl API, in order to work around an Android OS bug when
recovering from a GPU process crash. Unfortunately the Magnifier
widget (shown when moving a text selection caret) does not work when
rendering using SurfaceControl.
This patch makes it so that we temporarily disable the SurfaceControl
path when a text selection is active, allowing the Magnifier to work.
Unfortunately this means that if a GPU process crash occurs while
there is an active selection we will be unable to recover. Hopefully
this turns out to be a relatively rare occurence.
Differential Revision: https://phabricator.services.mozilla.com/D153454
We do some initialization of gfxFontSrcURI and gfxFontFaceSrc that is
main thread only on the DOM worker threads. These portions of the
initialization can easily be deferred to on demand access since they are
only ever used on the main thread itself.
Differential Revision: https://phabricator.services.mozilla.com/D153461
Bundled fonts were not picked up because also child processes need to
register them.
Also, they were assigned User visibility, instead of Base, which was
not coherent with other platforms.
Differential Revision: https://phabricator.services.mozilla.com/D150400
We need to pad e.g. nv12 4:2:0 formats in order to have integer-sized
chroma planes.
But also to avoid needing laser-focused testing for this case, just
unconditionally pad odd-sizes to even numbers.
* Test handling of odd-number-sized surfaces.
Differential Revision: https://phabricator.services.mozilla.com/D152797
Pre-cache the clip set -> node information as entries are pushed
on to the clip-tree builder stack.
This page is still not fast (it's a worst case for our current
code with box-shadow clips) but it's better than without this
patch (and we have plans to optimize the box-shadow case).
Differential Revision: https://phabricator.services.mozilla.com/D152956
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
This patch moves EqualsIgnoreCase to ns[T]StringObsolete, and removes
the aCount argument, instead migrating callers to use `StringBeginsWith`
with a case-insensitive comparator.
In addition, nsTStringRepr::Compare was removed and replaced with either
calls to methods like `StringBeginsWith` or the global `Compare` method.
These changes required some modifications at call-sites but should make
the behaviour less surprising and more consistent.
Differential Revision: https://phabricator.services.mozilla.com/D148299
In this patch, we make gfxFont use normal AddRef/Release semantics, and
instead now hold a strong reference to it inside the cache. At all times
a font should be in the expiration tracker, and whenever a lookup is
performed, we mark it as used.
When the tracker attempts to expire an entry, we check to see if the
only strong reference is inside the cache itself. If so, it is deleted.
If not, we mark it as used again instead of expiring it.
This has the advantage of making gfxFont::Release cheaper when there is
only one outstanding reference left outside the cache. It used to
acquire the gfxFontCache mutex in order to reinsert the font into the
expiration tracker when the last strong reference was cleared. This is a
very common case since the typical use case is only the main thread is
interacting with the cache, one font reference at a time.
This does not completely restore us to the previous performance
observed, but it does reclaim half of the original design benefit while
remaining threadsafe.
Differential Revision: https://phabricator.services.mozilla.com/D153110
Make sure to use the same scale the browser-chrome would actually use by
rounding to full app units.
This is especially visible with 1.5 text scale factor.
Differential Revision: https://phabricator.services.mozilla.com/D153099
We need to exclude shared clip roots if the hierarchy contains a
complex clip, as the shared clip applied by the tile cache during
compositing doesn't support complex clips.
Differential Revision: https://phabricator.services.mozilla.com/D152961
Addresses a coverity warning. The problem looks very benign but the work around is simple and it's good to keep the volume static analysis warnings in check.
Differential Revision: https://phabricator.services.mozilla.com/D152525
This patch refactors how clip chains are internally represented and used
during scene and frame building. The intent is to make clip processing
during frame building more efficient and consistent. Additionally, this
work enables follow ups to cache the result of clip-chain builds between
frame and scene builds.
These changes will significantly reduce the cost of the visibility pass
for the common case when not much content has changed. In this patch,
the public API for clipping remains (mostly) the same, in order to allow
landing and stabilising this work without major changes to Gecko. However,
a longer term goal is to make the public WR clip API more closely match
the internal representation, to reduce work done during scene building.
Clips on a primitive can be categorized into two buckets. The first are
local clips that are specific to the primitive and move with it. These
could essentially be considered part of the definition of the primitive
itself. The second are a hierarchy of clips that apply to one or more
items, and may move independently of the primitive(s) they clip. These
clips are things like scroll regions, stacking context clips, iframe
clip regions etc. On (real world) pages, the clip hierarchy is typically
quite shallow, with a small number of clips that are shared by a large
number of primitives.
Finding clips that are shared between primitives is both required (for
things such as determining which picture cache slice a primitive can
be assigned to, while applying the shared clips during composition), and
also a potential optimization (processing shared clips only once and
caching this clip state similar primitives).
The public clip-chain API has two complexities that make the above
difficult and time consuming for WR to determine. It was possible to
express a clipping hierarchy both via the legacy clip parenting path
(via `ClipId` definitions) and also via clip-chains (the `parent`
field of a `ClipChain`). Second, clip-chains themselves can define
an arbitrary number and ordering of clips. Clips can also implicitly
apply to primitives via parent stacking contexts and iframes, but must
sometimes be removed (when an intermediate surface is created) for
performance reasons.
The new internal representation provided by this patch introduces a
`ClipTree` structure which is built during scene building by accumulating
the set of clips that apply to a primitive from all explicit and implicit
sources, and grafting this on to the existing clip-tree structure.
This provides WR a simple way to determine which clips are shared between
primitive (by checking ancestry) and reduces the size of the internal
representation (by sharing clips where possible rather than duplicating).
Interning is still used to identify parts of the clip-tree that define
the same clipping state.
Specific changes in this patch:
* Remove legacy `ClipId` style parenting support (in conjunction with
previous patches)
* Remove the public API ability to specify the clip on a primitive via
`ClipId` (it must now be a clip-chain)
* Remove `combined_local_clip_rect` from `PrimitiveInstance`, reducing
the size of the structure significantly
* Introduce `ClipTree` used during frame building, which is created by
`ClipTreeBuilder` during scene building
* Separate out per-primitive clip concept (`ClipTreeLeaf`) from clipping
hierarchy (`ClipTreeNode`). In future, more elements will be moved to
the `ClipTreeLeaf` and the state of each `ClipTreeNode` will be cached)
* Simplify the logic to disable / remove clips during frame building that
are applied by parent surface(s)
* Port hit-testing to be based on `ClipTree` which is simpler, faster and
also resolves some edge case correctness bugs
* Use a simpler and faster method to find shared clips during picture
cache slice assignment of primitives
* Update wrench to use the public clip-chain API definition changes
This patch already introduces some real-world optimizations (for example,
`displaylist_mutate` becomes 6% faster overall), but mostly sets things
up for follow up patches to be able to cache clip-state between frames,
which should result in much larger wins.
Differential Revision: https://phabricator.services.mozilla.com/D151987
The patch from 1780321 relaxes shared surface allocation, by allowing
surfaces to be shared even if they exist for >1 pass. However, it has
a logic bug - _non shared_ surfaces that are created may then be
allocated from as a shared surface if the `free_after` matches. This
restores the `is_shared` logic that used to exist, which fixes this
edge case (and still allows the performance optimization on the cases
that were fixed by 1780321).
Differential Revision: https://phabricator.services.mozilla.com/D152707
BorrowSnapshot can be called by OffScreenCanvas in various places that may send
a SourceSurfaceWebgl to the main thread. If it did not originate from the main
thread, then this can cause multiple threads to use it. In general we want to
avoid this. For now, override BorrowSnapshot and make it always force a Skia
snapshot that can be safely shared between threads instead of SourceSurfaceWebgl.
Differential Revision: https://phabricator.services.mozilla.com/D152417
This prevents copies and avoids the hack we have to avoid this, which
right now is using nsDependent{C,}String.
Non-virtual actors can still use `nsString` if they need to on the
receiving end.
Differential Revision: https://phabricator.services.mozilla.com/D152519
