This timestamp is provided by the system on macOS, and estimated as "the next
vsync" on all other platforms.
On macOS, the output time increments in very consistent amounts. The timestamp
is independent of when exactly the vsync callback ends up running, so it is less
vulnerable to unfortunate thread scheduling.
This makes it a more reliable source for picking video frames, for example.
Differential Revision: https://phabricator.services.mozilla.com/D83828
* Majorly simplity CanvasRenderer
* Replace GLScreenBuffer with trivial GLSwapChain
* Use descriptor structs so that future SharedSurface changes aren't so painful
to propagate
* Mortgage/strip out more OffscreenCanvas code for now
Differential Revision: https://phabricator.services.mozilla.com/D75055
* Majorly simplity CanvasRenderer
* Replace GLScreenBuffer with trivial GLSwapChain
* Use descriptor structs so that future SharedSurface changes aren't so painful
to propagate
* Mortgage/strip out more OffscreenCanvas code for now
Differential Revision: https://phabricator.services.mozilla.com/D75055
* Majorly simplity CanvasRenderer
* Replace GLScreenBuffer with trivial GLSwapChain
* Use descriptor structs so that future SharedSurface changes aren't so painful
to propagate
* Mortgage/strip out more OffscreenCanvas code for now
Differential Revision: https://phabricator.services.mozilla.com/D75055
* Majorly simplity CanvasRenderer
* Replace GLScreenBuffer with trivial GLSwapChain
* Use descriptor structs so that future SharedSurface changes aren't so painful
to propagate
* Mortgage/strip out more OffscreenCanvas code for now
Differential Revision: https://phabricator.services.mozilla.com/D75055
I had to mess with the refcounting of Display (and hence destructors) because we create a NewRunnableMethod inside Display that holds a pointer to |this|. There are versions of NewRunnableMethod that don't take a ref but I'm not sure of the lifetime of Display, so easier to just take a ref since several of the subclasses are already refcounted.
Differential Revision: https://phabricator.services.mozilla.com/D71303
I had to mess with the refcounting of Display (and hence destructors) because we create a NewRunnableMethod inside Display that holds a pointer to |this|. There are versions of NewRunnableMethod that don't take a ref but I'm not sure of the lifetime of Display, so easier to just take a ref since several of the subclasses are already refcounted.
Differential Revision: https://phabricator.services.mozilla.com/D71303
For Win32k lockdown, we need to remove the content processes' ability to
call GetICMProfileW(). Since it needs this to retrieve the output color
profile, a new synchronous call is added that allows it to request the
parent process to read this file on its behalf.
The contents of the file are now being cached as well, as this should help
ease some of the increased parent process I/O caused by the children not
being able to do this in their process anymore.
For performance reasons, during launch this information is passed directly
to the child through the SetXPCOMProcessAttributes call
Differential Revision: https://phabricator.services.mozilla.com/D66126
--HG--
extra : moz-landing-system : lando
Currently, the GetCMSOutputProfile() and related methods pass their output
using the old C-style "ptr, len" parameters. This makes them more difficult
to deal with later in this change when they need to be safely passed over IPC.
This refactors them to return nsTArray<uint8_t> results instead. I also
removed some old cruft and refactored the existing code.
Differential Revision: https://phabricator.services.mozilla.com/D63583
--HG--
extra : moz-landing-system : lando
We need to provide separated dmabuf configurations for WebGL and Texture backends
as we want to enable dmabuf for WebGL only right now.
Depends on D59487
Differential Revision: https://phabricator.services.mozilla.com/D59488
--HG--
extra : moz-landing-system : lando
I'm not quite familiar with the history of this code, but Gnome a11y settings
set the scale to 1.25 (which gives 120dpi). We were rounding it away, which
seems quite unfortunate.
Differential Revision: https://phabricator.services.mozilla.com/D58279
--HG--
extra : moz-landing-system : lando
Lets Wayland sessions run vsync off wayland surface frame callbacks by creating
an interface for widgets to return a local VsyncSource, if applicable.
This interface is currently used for the compositor, and for refresh drivers
in the parent process. It is not yet used for vsync in content processes.
Differential Revision: https://phabricator.services.mozilla.com/D28430
--HG--
extra : moz-landing-system : lando
Let's use single Wayland configuration point at gfxPlatformGtk instead of various GDK_IS_X11_DISPLAY() calls.
Also provide info about enabled DMABuf surfaces when Wayland backend is used.
Depends on D46842
Differential Revision: https://phabricator.services.mozilla.com/D46843
--HG--
extra : moz-landing-system : lando
Let's use single Wayland configuration point at gfxPlatformGtk instead of various GDK_IS_X11_DISPLAY() calls.
Also provide info about enabled DMABuf surfaces when Wayland backend is used.
Depends on D46842
Differential Revision: https://phabricator.services.mozilla.com/D46843
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
Currently it's completely unclear at use sites that the getters for `once`
static prefs return the pref value from startup, rather than the current pref
value. (Bugs have been caused by this.) This commit improves things by changing
the getter name to make it clear that the pref value obtained is from startup.
This required changing things within libpref so it distinguishes between the
"base id" (`foo_bar`) and the "full id" (`foo_bar` or
`foo_bar_DoNotUseDirectly` or `foo_bar_AtStartup` or
`foo_bar_AtStartup_DoNotUseDirectly`; the name used depends on the `mirror` and
`do_not_use_directly` values in the YAML definition.) The "full id" is used in
most places, while the "base id" is used for the `GetPrefName_*` and
`GetPrefDefault_*` functions.
(This is a nice demonstration of the benefits of the YAML file, BTW. Making
this change with the old code would have involved adding an entry to every
single pref in StaticPrefList.h.)
The patch also rejigs the comment at the top of StaticPrefList.yaml, to clarify
some things.
Differential Revision: https://phabricator.services.mozilla.com/D38604
--HG--
extra : moz-landing-system : lando
The patch also removes the layers.mlgpu.enable-container-resizing pref, because
it's dead.
Differential Revision: https://phabricator.services.mozilla.com/D36159
--HG--
extra : rebase_source : e215d584aed18f865d2e8d00a78e76e9b0323e6e
Jonathan Kew
Mihai Alexandru Michis
Martin Stransky
Andrew Osmond
Markus Stange
Jeff Muizelaar
Simon Giesecke
Robert Mader
Jeff Gilbert
Bogdan Tara
Dorel Luca
Kartikaya Gupta
Razvan Maries
Chris Martin
Emilio Cobos Álvarez
Kenny Levinsen
Oana Pop Rus
Lee Salzman
Cosmin Sabou
Nicholas Nethercote
Barret Rennie