To look up/instantiate platform fonts based on CSS font properties, we create a gfxFontGroup from an nsFont and other attributes; this is currently cached in an nsFontCache attached to the nsDeviceContext.
However, this assumes that the mapping to platform fonts will be the same for all documents using the given device context. In a world where visibility of platform fonts to the page may be restricted, and may depend on the individual document (e.g. if the user disables tracking protection for a particular site), the mapping represented by nsFontCache may vary, and determining how to resolve a given font request will need access to the requesting document in order to know what visibility it is allowed.
To support this, this patch moves the nsFontCache from nsDeviceContext to nsPresContext. In itself, this should cause no visible change in behavior, but it provides a basis for the patches that will follow in bug 1715501.
It's likely that this will have some effects on individual performance tests, depending on the exact content and sequencing of page loads, because of changed caching behavior. E.g. having a per-presContext cache may sometimes mean that we no longer take advantage of a cached gfxFontGroup that a previously-loaded page created; but on the other hand the caches will tend to be smaller and have faster lookups.
My testing so far suggests that we will see some apparent regressions, alongside some improvements, but that overall there should be little change. I'd like to get this change landed separately, before any of the actual font-visibility behavior changes, so that we can more clearly see and isolate any unexpected effects.
Differential Revision: https://phabricator.services.mozilla.com/D122715
This is a bandaid designed to cope with a subset of the encountered transforms that
may be applied to a pattern inside FillRect. The existing code did not consider the
transform at all that might be applied to a pattern when it tried to manually clip
the geometry to a no-repeat pattern.
This manual clipping only seems to occur in FillRect, whereas no-repeat patterns
are not properly handled anywhere else in canvas entry-points. To fix this more
generally requires a clamp-to-transparent tile mode (like Skia's decal or Cairo's
none) which we can't currently rely upon with our D2D support. However, that is
much beyond the scope of this temporary workaround.
Differential Revision: https://phabricator.services.mozilla.com/D122186
This will make implementing the new behavior behind a pref
really straight-forward, and is generally nicer.
Depends on D121858
Differential Revision: https://phabricator.services.mozilla.com/D121705
After we enabled support for large ArrayBuffers on 64-bit platforms, we could
also create larger ImageData objects. WebIDL bindings check for large ArrayBuffer{View}s
but not when they're wrapped in an ImageData.
It seems safest to limit ImageData arrays to the old 2 GB for now until we need larger
buffers.
Differential Revision: https://phabricator.services.mozilla.com/D121595
See bug 1716641 comment 4 for a way this can happen.
I don't know what the best way to add a test for this is / whether it's
worth adding one?
Differential Revision: https://phabricator.services.mozilla.com/D118307
This changes font-family storage to reuse the rust types, removing a
bunch of code while at it. This allows us to, for example, use a single
static font family for -moz-bullet and clone it, rather than creating a
lot of expensive copies.
Differential Revision: https://phabricator.services.mozilla.com/D118011
And make sure we return the surface of the right size for canvas, which
makes that assumption in a bunch of places.
Depends on D114686
Differential Revision: https://phabricator.services.mozilla.com/D114687
In the DrawTargetRecording case we create new GradientStopsRecording each time
and holding onto them in the content process can mean they take a very large
amount of memory in the GPU process, if a script deliberately creates lots of
unique stops.
In the non-recording case then the GradientStops are cached in the content
process anyway.
Differential Revision: https://phabricator.services.mozilla.com/D109792
CLOSED TREE
Backed out changeset 12ee10496a34 (bug 1629381)
Backed out changeset b0eba102423a (bug 1629381)
Backed out changeset 383fec2e815c (bug 1629381)
Shifted the zero-check after width and height are clamped to int32_t. Fixes the use case where width and height are floats > 0 but < 1. These values are clamped to 0, but no error is thrown, as opposed to the desired behavior. Deleted corresponding test ini file, since it is now expected to PASS.
Now also fixes a test that started failing and checked something against the spec, (credit to @emilio)
Differential Revision: https://phabricator.services.mozilla.com/D100597
Shifted the zero-check after width and height are clamped to int32_t. Fixes the
use case where width and height are floats > 0 but < 1. These values are clamped
to 0, but no error is thrown, as opposed to the desired behavior. Deleted
corresponding test ini file, since it is now expected to PASS.
Differential Revision: https://phabricator.services.mozilla.com/D100597
Added an option to use ConicGradient API as a preference and removed the
corresponding expected FAILing test, over @ntim's implementation.
Differential Revision: https://phabricator.services.mozilla.com/D100554
This lifts a bunch of string conversions higher up the stack, but allows
us to make the servo code use utf-8 unconditionally, and seemed faster
in my benchmarking (see comment 0).
It should also make a bunch of attribute setters faster too (like
setting .cssText), now that we use UTF8String for them (we couldn't
because we couldn't specify different string types for the getter and
setters).
Differential Revision: https://phabricator.services.mozilla.com/D99590
This allows us to avoid instantiating separate gfxFont objects when content is tagged
with different 'lang' attributes, yet ends up using the same fonts (e.g. Wikipedia may
use a default font such as Arial for language names/links that are tagged with several
dozen different languages).
Differential Revision: https://phabricator.services.mozilla.com/D96978
