The only use of this type used to be carrying around an owning reference
to a thread-local. However, since bug 1577439 we're leaking the
allocation intentionally, so we can simplify the code to explicitly use
`Box::leak()`, which in turn removes all unsafe usage around these, and
allows us to drop the owning_ref dependency altogether.
Differential Revision: https://phabricator.services.mozilla.com/D209912
The fork server replaces the process's `argv` and `environ` with
heap-allocated strings received over IPC; if those strings are later
unlinked from those vectors, they will be seen as leaked. Also, we
have an implementation of `setproctitle` (a BSD feature that has to be
emulated somewhat hackily on Linux) which copies the process's original
`argv` and `environ` strings into the heap so the original space can be
reused; this can also cause (finite) leaks when those strings are later
discarded.
Given that we already tell Valgrind to ignore leaks caused by use of
`setenv` and similar, this patch likewise suppresses those leaks.
Differential Revision: https://phabricator.services.mozilla.com/D201190
For WebGPU, we produce the textures in the compositor process and the
content process doesn't need to be that involved except for hooking up
the texture to the display list. Currently this is done via an external
image ID.
Given that WebGPU needs to work with OffscreenCanvas, it would be best
if its display pipeline was consistent whether it was gotten from an
HTMLCanvasElement, OffscreenCanvas on the main thread, or on a worker
thread. As such, using an AsyncImagePipeline would be best.
However there is no real need to bounce the handles across process
boundaries. Hence this patch which adds CompositableInProcessManager.
This static class is responsible for collecting WebRenderImageHost
objects backed by TextureHost objects which do not leave the compositor
process. This will allow WebGPUParent to schedule compositions directly
in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D138588
For some reason, the execution of dbus-launch causes problems after bug
1734934, even though we were executing dbus-launch before. We don't
actually care about valgrind'ing its execution, though, because it's a
system program.
Differential Revision: https://phabricator.services.mozilla.com/D136312
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
In practice we already only use SourceSurfaceSharedData as our
rasterized image backing. This means we no longer need to lock the data
to keep it in memory (when we used volatile memory), nor to try to
optimize the surface for the DrawTarget.
Differential Revision: https://phabricator.services.mozilla.com/D124476
Valgrind detects a condition depending on uninitialized value in update_texture_cache. I first ran into this in bug 1716579, and as patch had a large impact on allocation/deallocation workloads with the texture cache, I couldn't decide with confidence that the patch wasn't faulty. In bug 1728618 which causes this error again, however, the patch is much simpler, doesn't interact with unsafe code and does not affect texture cache workloads so it gives me much better confidence that this valgrind error is either a false positive or a miscompilation.
Differential Revision: https://phabricator.services.mozilla.com/D124444
