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
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
The purpose of this is to remove as many docstrings from CommandProvider
classes to make the step of moving commands out of classes simpler.
Where possible, the docstring has been moved to or merged with the function.
Differential Revision: https://phabricator.services.mozilla.com/D123288
This step removes all the dependencies of mach commands to
having a MachCommandBase as the `self` by using the `command_context`
argument instead. This also removes any remaining statefulness from those
classes that implement mach commands, ultimately making it easier to move
existing commands out of classes in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D118058
Mike Hommey
Cristina Horotan
Ryan VanderMeulen
Emilio Cobos Álvarez
serge-sans-paille
Jed Davis
Gregory Pappas
stransky
Cristian Tuns
Butkovits Atila
Lee Salzman
Natalia Csoregi
Marco Castelluccio
Erik Nordin
Jonathan Kew
Andrew Osmond
Shravan Narayan
Alex Lopez
Noemi Erli
Nicolas Silva
Sandor Molnar
Brindusan Cristian