The goal is to allow the brush flags to use more bits in a followup changes.Currently it uses all of its available 8 bits, this patch allows it to use up to 12.
Differential Revision: https://phabricator.services.mozilla.com/D140967
This check seems to fail even if the VR pref is enabled. I think this is
because we are running this code while very early in process startup.
I think it will not introduce risk because the other process in this case
will be the parent process, so if that's been taken over then we've already
lost.
This also seems to fix the leak that I had to ignore before, probably
because the VR process wasn't even starting up properly before, so I've
removed the leak threshold I had to add.
Differential Revision: https://phabricator.services.mozilla.com/D141170
test_device_reset.html checks if canvas works after device reset. Since Bug 1757879 fix, windowutils.triggerDeviceReset() does the device reset handling asynchronously in gecko. And the device reset happened during testing canvas since 1757879 fix. The canvas testing needs to happen after the gecko's device reset handling.
The change adds more latency for waiting device reset completed in gecko.
Differential Revision: https://phabricator.services.mozilla.com/D141178
Every `VsyncSource` currently only has a single `Display` associated with it.
This means that we're not making use of the `Display` abstraction at all.
This patch gets rid of `Display` by merging it into `VsyncSource`.
Originally, the intention of the `Display` abstraction was to use it for
per-monitor vsync. There would be one software `VsyncSource` and one hardware
`VsyncSource`, and the hardware `VsyncSource` would have one `Display` per
screen. But in reality, things have played out differently: The only platform
with per-monitor vsync is currently Linux Wayland, which has per-**widget**
vsync. And it has chosen to have one `VsyncSource` per widget, with a single
`Display` each.
For the macOS implementation of per-monitor vsync, I think it also makes
sense to have one `VsyncSource` per screen.
We already need to handle switching between VsyncSources, for switching
between software and hardware vsync, if the pref `layout.frame_rate` is
changed. So we might as well reuse that same switching capability for
switching between screens, when a window moves between screens or when a
tab moves between windows on different screens.
Differential Revision: https://phabricator.services.mozilla.com/D140891
The brush shader didn't take the anti-aliased code path if the transform was axis-aligned, this patch adds an extra flag to force the code path in the shader.
Differential Revision: https://phabricator.services.mozilla.com/D139958
The goal is to allow the brush flags to use more bits in a followup changes.Currently it uses all of its available 8 bits, this patch allows it to use up to 12.
Differential Revision: https://phabricator.services.mozilla.com/D140967
IsSyncPagePrinting() only had one implementation which unconditionally
returned true.
So, any code that was conditioned on !IsSyncPagePrinting() is necessarily
dead/unreachable.
These are also crashing due to a null deref in mPrintTarget which might
happen if print is aborted.
Differential Revision: https://phabricator.services.mozilla.com/D140988
When using webrender's draw compositor with partial present enabled,
we treat the entire area of all promoted compositor surfaces as
dirty. However, if a compositor surface is moved or reduced in size
this is buggy - the *new* area of the surface will be treated as
dirty, but the additional area it used to occupy will not be. This
means that area may not be updated properly when compositing, leaving
stale content behind.
To fix this, keep track of the combined area of all promoted
compositor surfaces. If the area on the new frame does not contain the
area from the previous frame, then request a full composite by setting
dirty_rects_are_valid to false.
Differential Revision: https://phabricator.services.mozilla.com/D140717
Previously, WR would recursively walk the entire picture
tree during each of the visibility, prepare and batching
passes. With this change, the prepare pass builds a tightly
packed command buffer of draw commands for each child surface
and/or picture cache tile. The batching pass now reads the
packed command buffers, meaning that no traversal of the
picture tree is required during batching.
This serves two purposes:
(1) It makes it possible to direct primitives within a
single picture to different render tasks. This isn't
yet used, but is a straightforward addition to how
command buffers work. This functionality will be used
to split primitives across render tasks where there
are readback boundaries (e.g. backdrop-filter and also
mix-blend-mode). The existing picture graph code ensures
that we then optimally allocate, batch and draw pictures
that contain these barrier style primitives.
(2) In the common case, where only a small portion of the
scene has changed during a frame, it's a significant
optimization to avoid another picture tree traversal.
Instead, the batching code will only end up iterating
small lists of the primitives that overlap the dirty
region for the given tile / child surface.
Differential Revision: https://phabricator.services.mozilla.com/D140159
This doesn't in itself make them thread-safe, but it provides a basis to do so by avoiding
dependence on the Preferences service at textrun-construction time.
The FontPrefs record is inert once constructed, so one approach to worker-thread use would
be to make it refcounted, and have the worker hold a strong reference to the record it's using,
so that it won't be affected if the main thread handles a pref-change and replaces its
FontPrefs. Alternatively, maybe we can just protect access with the same lock as other uses
of the font list, once that is in place (bug 1756474).
Differential Revision: https://phabricator.services.mozilla.com/D140914
This replaces the sharing of SharedFontInstanceMap with a new structure
SharedFontResources that can be used to trade a mechanism between threads
of a single Renderer instance for de-duplicating fonts and font instances.
SharedFontResources stores maps of FontTemplates and FontInstances as well
as a new FontKeyMap and FontInstanceKeyMap which handles the mapping of
namespace-local font keys to a shared key. The shared key then maps to
the real, de-duplicated resource (template or instance) which has a lifetime
beyond that of any individual namespace that may refer to it. Reference
counting is used to track the lifetime of the shared key so that when no key
map entries refer to the shared key any longer, it will then expire and
be cleaned up. This does cause some complications with clearing a namespace
in that rather than simply crawling through a table looking for resources
with a given IdNamespace, we have to check for shared keys that have expired
when clearing a namespace caused the last references to their mappings
to be removed.
Given that ApiResources handles the up-front addition of font templates
and instances, while ResourceCache within the RenderBackend handles deletion,
most of these mappings have to be shared between threads, which is why they
live within SharedFontResources. When resource updates are processed by
either ApiResources or ResourceCache, we create a shared key as necessary to
add the font resource, and then delete the shared font resource when a resource
update caused the last reference to the resource's shared key to expire.
This only tries to de-duplicate fonts within a single Renderer (window). Since
each Renderer has its own texture cache and dependent glyph cache, sharing
across multiple windows would require extra complication with storing font
bitmaps outside of the texture cache and outside the Renderer instance itself.
For the sake of simplicity and to better understand how de-duplication impacts
performance, this patch only tries to address sharing within a single window.
Differential Revision: https://phabricator.services.mozilla.com/D140561
DrawSurfaceWithShadow is supposed to ignore transforms but still support clipping.
It appears that DrawTargetD2D1 for some reason never actually implemented clipping.
The DrawImage calls on the DC just need to happen within the bounds of PrepareForDrawing
and FinalizeDrawing. Since PrepareForDrawing handles the overriding of the blend mode
via SetPrimitiveBlend, we need to use DrawImage with D2D1_COMPOSITE_MODE_SOURCE_OVER
so that it will blend appropriately.
Differential Revision: https://phabricator.services.mozilla.com/D140798
A better solution would check against the same value as reported by gfxConfig, which takes the pref as well as whether webgpu was blocked (for example due to buggy drivers) into account, but this still is good sanity check and easy to uplift.
Differential Revision: https://phabricator.services.mozilla.com/D140535
