When we are rendering dark-on-light text, we invert the bitmap after
rendering to produce a standard white-on-black mask, since we must actually
render that as black-on-white to get CoreText to produce the correct dilation.
However, when we know we're rendering bitmap fonts for emoji, we don't actually
want this inversion to happen at all. So we need to ensure bitmaps go through
the normal light-on-dark path that doesn't do this.
Differential Revision: https://phabricator.services.mozilla.com/D154777
If viewport clipping is applied to the bounds of glyphs, we can end up finding the
wrong entry if the clipping would differ, since we no longer compare the bounds to
the entry bounds when searching for a matching entry in an effort to reduce the
amount of bounds computations in the common case.
To workaround this, each entry now remembers its full, unclipped bounds. Upon
finding a candidate entry, we offset the full bounds to the new offset and reapply
clipping. If the bounds then match with the old clipped bounds with the new offset
applied, then we know the amount of applied clipping is the same, and it is safe
to reuse the entry.
Differential Revision: https://phabricator.services.mozilla.com/D154490
In this patch, we ask the media engine to return a handle for shareable
dcomp surface, which will then be packaged into a new texture data type
and being shared with the GPU process via the video bridge.
DcompSurfaceImage is the image which contains the handle texture data,
which doesn't support being accessed in the content process. When the
compositor uploads the image to the GPU process, the corresponding
texture host will be created.
The render texture host will be created by that texture host, and it
will be used in DCLayerTree. In DCLayerTree, we create a new type of
surface for our dcomp handle. DCSurfaceHandle will ask the render
texture host to reconstruct the surface by the handle shared from the
remote process (the handle is actually duplicated to the parent process
first due to the sandbox policy, and then be duplicated to the GPU
process later)
DCSurfaceHandle will attach that surface to its visual in order to
display the video frame directly. In the whole process, it's not
possible for Gecko to access any decoded video data which is protected by the
media engine itself.
Depends on D149941
Differential Revision: https://phabricator.services.mozilla.com/D151019
In this patch, we ask the media engine to return a handle for shareable
dcomp surface, which will then be packaged into a new texture data type
and being shared with the GPU process via the video bridge.
DcompSurfaceImage is the image which contains the handle texture data,
which doesn't support being accessed in the content process. When the
compositor uploads the image to the GPU process, the corresponding
texture host will be created.
The render texture host will be created by that texture host, and it
will be used in DCLayerTree. In DCLayerTree, we create a new type of
surface for our dcomp handle. DCSurfaceHandle will ask the render
texture host to reconstruct the surface by the handle shared from the
remote process (the handle is actually duplicated to the parent process
first due to the sandbox policy, and then be duplicated to the GPU
process later)
DCSurfaceHandle will attach that surface to its visual in order to
display the video frame directly. In the whole process, it's not
possible for Gecko to access any decoded video data which is protected by the
media engine itself.
Depends on D149941
Differential Revision: https://phabricator.services.mozilla.com/D151019
When creating an ImageContainer for OffscreenCanvas, we were holding a
lock for the OffscreenCanvas. The constructor for an ImageContainer may
do a sync call back to the ImageBridgeChild thread in the content
process, unlike its typical async notifications for other operations
once it has been created.
There is no need to hold the OffscreenCanvas lock while we create the
ImageContainer itself, so it is best to not to avoid any potential
deadlocks.
Similarly, we should avoid holding the lock when performing the
readback, if any, for the canvas during the display commit.
Differential Revision: https://phabricator.services.mozilla.com/D154556
Rather than allocating TexturePacker children individually, allocate an array
of all the children at once to cut the number of memory allocations in half.
Depends on D154118
Differential Revision: https://phabricator.services.mozilla.com/D154182
Now that we're actually hitting cache entries in the glyph cache, it turns out
always computing the local glyph bounds can be expensive, especially since they
should never really change. Instead, rely on the bounds that were initially
computed when an entry is inserted into the cache, and just change their relative
offset based on the current transform. This way, in the common case of a cache
hit, we never need to compute the bounds.
Differential Revision: https://phabricator.services.mozilla.com/D154118
Offsets were being specified in quantized space (i.e. scaled 1-4x) whereas bounds were
still in the original coordinate space. The bounds need to be transformed by the same
quantization scale so that glyph cache entries compare correctly. This was preventing
cache entries from being properly reused.
Differential Revision: https://phabricator.services.mozilla.com/D154102
This implements a rudimentary form of hash chaining for cache entries that reduces
the number of entry comparisons by about an order of magnitude. It's a bit of a bother
to use an actual hash table here since right now the code expects to be able to have
random access to cache entries in the list, and the MFBT hash table is not quite set
up for this. Instead, this just adds a reasonable fixed number of buckets to bring
the list size better under control.
Differential Revision: https://phabricator.services.mozilla.com/D154101
```
// We guarantee our robustness via these requirements:
// * Object.MutTiedFields() gives us a tuple,
// * where the combined sizeofs all field types sums to sizeof(Object),
// * (thus we know we are exhaustively listing all fields)
// * where feeding each field back into ParamTraits succeeds,
// * and ParamTraits is only automated for BytesAlwaysValidT<T> types.
// (BytesAlwaysValidT rejects bool and enum types, and only accepts int/float
// types, or array or std::arrays of such types)
// (Yes, bit-field fields are rejected by MutTiedFields too)
```
BytesAlwaysValidT<T> is the same as the IsTriviallySerializable<T> that
it replaces, however the emphasis is different, and should discourage
tagging structs as IsTriviallySerializable, since they more clearly
aren't BytesAlwaysValid.
Differential Revision: https://phabricator.services.mozilla.com/D151676
Since the BufferTextureData is getting created based on ImageDataSerialize::ComputeRGBBufferSize,
the stride may be padded for alignment which doesn't agree with the simple calculation duplicated
here. In general, it is less error-prone to just ask the BufferTextureData itself for its buffer
size, so just do that here instead rather than trying to make duplicate calculations with invalid
assumptions.
Differential Revision: https://phabricator.services.mozilla.com/D153868
Otherwise seemingly lightweight but unusual calls like
drawArrays(offset:1.5billion) will try to allocate a very large gpu
buffer, which sometimes takes a very long time.
This is unusual and we shouldn't encourage it, so let's just add a
limit. 10M is 160MB, which is generally big enough but not too big.
Differential Revision: https://phabricator.services.mozilla.com/D153533
Previously, we checked this but only if there was a texture bound to the
tex unit. However technically we're supposed to check regardless. ANGLE
and Mesa both do, which causes this error.
Differential Revision: https://phabricator.services.mozilla.com/D153422
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
`Maybe` isn't is_trivially_copyable, and std::optional isn't either on
the old libstdc++ we use from gcc7 still.
I'm working on more robust approach to serialization but that's beyond
the scope of this bug.
Differential Revision: https://phabricator.services.mozilla.com/D151421
The remaining methods in ns[T]StringObsolete are all find+replace methods for
nsTSubstring. These were migrated in a similar way to the find methods, and
partially updated to avoid using methods from nsStringObsolete.cpp.
This change removes the ns[T]StringObsolete.cpp files completely, as they are
no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D148301
mWebglValid gets initialized to false, but it will never get reset to true until the next
frame, causing us to render into Skia the first frame rather than accelerate. Therefor, we
should just initialize it to valid. Since it is cleared to zero initially, this is safe.
Differential Revision: https://phabricator.services.mozilla.com/D151896
Andrew Osmond
Lee Salzman
Marian-Vasile Laza
Paul Bone
alwu
Kelsey Gilbert
Norisz Fay
Fabrice Desré
Andreea Pavel
Mark Banner
Iulian Moraru
Nika Layzell
Chun-Min Chang