Bug 1959801 removed the `remove_dir_all` crate. However, there was a regression we didn't discover until Firefox 140 reached stable: third-party DLL injection on Windows caused problems for the call sites that had had usages of `remove_dir_all::remove_dir_all` replaced with `std::fs::remove_dir_all`!
DLL injection by third parties were causing these crashes because they incorrectly detour calls to `NtOpenFile`, crashing with Rust's current usage of it in `std::fs::remove_dir_all`. The issue has been reported upstream as [rust#143078], and a mitigation is in place in Rust's Nightly release channel. At time of writing this patch message, the fix is projected to become available in a stable Rust toolchain with version 1.90—roughly 11 weeks away.
[rust#143078]: https://github.com/rust-lang/rust/issues/143078#issue-3181510282
After considering multiple mitigation options, this patch represents the decision of some stakeholders (@gstoll, @dmeehan, @yjuglaret, @gsvelto, @leggert, @ErichDonGubler) to mitigate the issue by directly backing out the patch for bug 1959801. The current plan is to eventually remove `remove_dir_all` again, once Rust 1.90 becomes the minimum supported version for `mozilla-central` (see bugs linked against bug 1973947 for more details), thus guaranteeing that our usage of `std::fs::remove_dir_all` is robust against this issue.
We may or may not engage with third parties to fix DLL injection; it has
not been decided at this time.
Original Revision: https://phabricator.services.mozilla.com/D256027
Differential Revision: https://phabricator.services.mozilla.com/D256040
As far as I can tell, this code does not rely on the slight differences provided by the `remove_dir_all` crate that make it different than `std::fs::remove_dir_all`, but #gfx-reviewers should please confirm that.
Differential Revision: https://phabricator.services.mozilla.com/D245133
When profiler takes async screenshot and WebRender uses layer compositor, WebRender tries to use only one swap chain without overlay.
Differential Revision: https://phabricator.services.mozilla.com/D246200
In addition, rename NotifyDidSceneBuild into ScheduleFrameAfterSceneBuild. Right now it is only used for that purpose but it would cause issues if we start relying on it to be called after all scene builds since with this patch we won't call it if we do not need a new frame.
Differential Revision: https://phabricator.services.mozilla.com/D245898
This patch is a preliminary refactoring to make it simpler to pass additional information to the C++ side and should not affect behavior.
In a followup patch the widget glue will have special handling for frames that need to be rendered but not presented.
Differential Revision: https://phabricator.services.mozilla.com/D245564
In addition, rename NotifyDidSceneBuild into ScheduleFrameAfterSceneBuild. Right now it is only used for that purpose but it would cause issues if we start relying on it to be called after all scene builds since with this patch we won't call it if we do not need a new frame.
Differential Revision: https://phabricator.services.mozilla.com/D245898
This patch is a preliminary refactoring to make it simpler to pass additional information to the C++ side and should not affect behavior.
In a followup patch the widget glue will have special handling for frames that need to be rendered but not presented.
Differential Revision: https://phabricator.services.mozilla.com/D245564
This also adds the plumbing for implementing the rounded compositor
clip in CoreAnimation and SWGL compositors, though they will be
implemented in follow up patches.
Differential Revision: https://phabricator.services.mozilla.com/D245166
This avoids repeated symbol lookups on macOS.
Maybe WrShaders is no longer the right name for this struct.
We could rename it to WrSharedGlState or something along those lines.
Differential Revision: https://phabricator.services.mozilla.com/D245679
This avoids keeping the thread blocked for too long in case the
call to glProgramBinary is slow. Slow glProgramBinary has been
observed with the Xclipse GPU driver.
Differential Revision: https://phabricator.services.mozilla.com/D245174
By itself, this makes wr_shaders_delete cheaper, because we won't
need to look up the GL symbols again when recreating the device.
But the actual reason I'm doing this is that I want to have
individual calls for each shader's preallocation, from separate
event loop tasks, and each of those calls will need a Device.
Differential Revision: https://phabricator.services.mozilla.com/D245173
By Bug 1957563, GpuProcessD3D11FencesHolderMap is changed to instantiate also in Parent process when GPU process does not exist. Then it seems better to change its name.
Differential Revision: https://phabricator.services.mozilla.com/D244684
Remove FenceInfo. Instead use GpuProcessFencesHolderId and GpuProcessD3D11FencesHolderMap.
GpuProcessD3D11FencesHolderMap is changed to instantiate also in Parent process when GPU process does not exist. Then it seems better to change its name. The name change is going to be handled in Bug 1958752.
Differential Revision: https://phabricator.services.mozilla.com/D244539
DXGIYCbCrTextureData uses keyed mutex for synchronization. But it is inefficient than FenceD3D11. And it caused the performance problem when DXGIYCbCrTextureData has multiple users like Bug 1956305
Differential Revision: https://phabricator.services.mozilla.com/D243622
DXGIYCbCrTextureData uses keyed mutex for synchronization. But it is inefficient than FenceD3D11. And it caused the performance problem when DXGIYCbCrTextureData has multiple users like Bug 1956305
Differential Revision: https://phabricator.services.mozilla.com/D243622
On macOS, the snapshotter creates its own GLContext.
Creating a GLContext spends some time (10ms+) looking up GL symbols.
The only purpose of the snapshotter is to capture screenshots for the profiler,
so this patch saves the symbol lookup cost when we're not capturing screenshots.
Profile: https://share.firefox.dev/4lbIDKj
Differential Revision: https://phabricator.services.mozilla.com/D243618
And use DebugMarker(1) to signify that the next item is a view-transition snapshot.
This specific marker is not meant to stay forever (although the infrastructure is), but it is useful right now.
Differential Revision: https://phabricator.services.mozilla.com/D242023
And use DebugMarker(1) to signify that the next item is a view-transition snapshot.
This specific marker is not meant to stay forever (although the infrastructure is), but it is useful right now.
Differential Revision: https://phabricator.services.mozilla.com/D242023
It is mostly working, but there are some tests that hit crashes and
asserts that we should sort out. For now, land it default-off.
This does implement other bits that are on by default tho, like creating
image frames for ::view-transition-new() pseudo-elements and so on. I
think that is fine (it's just that for now they are all transparent).
Differential Revision: https://phabricator.services.mozilla.com/D239382
