The glyphs in Apple Symbols tend to be visually quite small relative to common text fonts,
so preferring STIXGeneral will give a less jarring appearance in some cases.
Differential Revision: https://phabricator.services.mozilla.com/D111534
On M1 machines, the fix from bug 1422855 was not effective; stopping and starting the
CVDisplayLink is not enough to cause it to switch to an active display. So we create
a new display link, which will pick an active display.
This patch is written to be minimum impact and easy to uplift. More cleanup is needed in the future.
Differential Revision: https://phabricator.services.mozilla.com/D106744
This fixes a problem where the callback just wouldn't be called for the duration
of about a minute after fast user switching. I'm hoping it'll also help with a
similar problem after screen lock and after sleep (bug 1682713).
The documentation for CVDisplayLinkStop says the following:
> In macOS 10.4 and later, the display link thread is automatically stopped if
> the user employs Fast User Switching. The display link is restarted when
> switching back to the original user.
This probably works for display links that were created before fast user
switching. However, we sometimes create a new CVDisplayLink while our user is
"in the background", and this new display link happily keeps running while we're
in the background. Then, when switching back to the original user, *that's* when
the display link is stopped. And then it eventually starts again. I'm not sure
what causes it to re-start.
Creating a CVDisplayLink while the machine is fast user switched to a different
user is probably not a well-excercised codepath. Things might work more reliably
if we keep reusing the same CVDisplayLink instance and just stop and start it
as needed. But that's a more risky change that I don't want to uplift.
Also, starting to listen for vsync while a different user is the "current" user
is probably a mistake anyway. We should find out if there's a way to suspend
compositing and drawing in that state. However, it seems that the window doesn't
enter the occluded state during this time, because in that case we would
de-activate the content docshell and not run requestAnimationFrame callbacks.
But the profiler clearly shows rAF running during the switched-away time.
I'm seeing the following display reconfiguration callbacks during fast user
switching, 2077750265 being the display link's current display:
```
[1] DisplayReconfiguration for 2077750265: BeginConfiguration
[2] DisplayReconfiguration for 1104977158: BeginConfiguration
[3] DisplayReconfiguration for 2077750265: Remove Disabled
[4] DisplayReconfiguration for 1104977158: Moved SetMain SetMode Add Enabled
[5] DisplayReconfiguration for 1104977158: BeginConfiguration
[6] DisplayReconfiguration for 2077750265: BeginConfiguration
[7] DisplayReconfiguration for 1104977158: Remove Disabled DesktopShapeChanged
[8] DisplayReconfiguration for 2077750265: Moved SetMain SetMode Add Enabled DesktopShapeChanged
```
With this patch, we restart the display link at notification 4 and 8.
In the future, we should switch to per-monitor (or per-window) vsync rather than
global vsync, and clean this whole situation up a little.
Differential Revision: https://phabricator.services.mozilla.com/D105868
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
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
There are multiple SurfacePools: Main thread painting and the non-WebRender compositors create a new pool per window, and WebRender creates one shared pool across all windows. The non-WebRender users set the pool size limit to zero, i.e. no recycling across paints. This preserves the pre-existing behavior.
WebRender's pool size is configurable with the gfx.webrender.compositor.surface-pool-size pref.
Every window holds on to a SurfacePoolHandle. A SurfacePoolHandle has an owning reference to the pool, via a surface pool wrapper. Once all handles are gone, the surface pool goes away, too.
The SurfacePool holds on to IOSurfaces and MozFramebuffers. Both are created on demand, independently, but are associated with each other.
A given NativeLayer uses only one surface pool handle during its lifetime. The native layer no longer influences which GLContext its framebuffers are created for; the GL context is now managed by the surface pool handle.
As a result, a NativeLayer can no longer change which GLContext its framebuffers are created by.
So in the future, if we ever need to migrate a window frome one GLContext to another, we will need to recreate the NativeLayers inside it. I think that's ok.
Differential Revision: https://phabricator.services.mozilla.com/D54859
--HG--
extra : moz-landing-system : lando
These functions were made public in 10.6. The oldest version we support is 10.9.
Differential Revision: https://phabricator.services.mozilla.com/D41813
--HG--
extra : moz-landing-system : lando
* Remove redundant virtual keywords
* Mark all destructors of inheriting classes as virtual for clarity
* Mark all classes without virtual destructor as final (exposed errors)
* Make destructor virtual where it needed to be (some were missing)
* Replace empty ({}) code declaration in header with = default
* Remove virtual unused methods
I probably missed some, it quickly became a rabbit hole.
Differential Revision: https://phabricator.services.mozilla.com/D26060
--HG--
extra : moz-landing-system : lando
The only caller wants CSS pixels, no need to go back and forth.
This is the last dependency on the pres context, I think, from the style system
font code.
Differential Revision: https://phabricator.services.mozilla.com/D19147
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Matthew Finkel
Timothy Nikkel
Andrew Osmond
Jonathan Kew
Iulian Moraru
Emilio Cobos Álvarez
Markus Stange
Mihai Alexandru Michis
Simon Giesecke
Kartikaya Gupta
Razvan Maries
Chris Martin
Dorel Luca
Markus Stange
Steven Michaud
Barret Rennie
Jean-Yves Avenard
Ryan Hunt
Tooru Fujisawa
Sylvestre Ledru
Miko Mynttinen
arthur.iakab