This adds a function GetHeterogeneousCpuInfo() to HAL, which
classifies the processor cores in to "big", "medium", and
"little". This is currently only implemented on Android, where it
works by parsing the maximum CPU frequency from sysfs.
When all CPUs have the same frequency they are all classified as
"big", and when there are only 2 different frequencies they are
classified as "big" and "little". All CPUs with a frequency in-between
the lowest and highest are classified as "medium".
This information can be used to count the number of each cores in each
category, eg for determining appropriate thread pool sizes. Or to
determine the indices of cores in a certain category, eg for setting
CPU affinity for certain threads.
Differential Revision: https://phabricator.services.mozilla.com/D188478
PerformanceHintManager is an Android API that allows the caller to
create a PerformanceHintSession, representing a workload shared by a
group of threads that should be completed within a target duration
each cycle. The actual duration spent working is reported each cycle,
and the system can then adjust scheduling of the threads accordingly
in order to hit the target going forward.
This patch adds the API to HAL along with an Android
implementation (and a nop fallback implementation for other
platforms).
Differential Revision: https://phabricator.services.mozilla.com/D186238
PerformanceHintManager is an Android API that allows the caller to
create a PerformanceHintSession, representing a workload shared by a
group of threads that should be completed within a target duration
each cycle. The actual duration spent working is reported each cycle,
and the system can then adjust scheduling of the threads accordingly
in order to hit the target going forward.
This patch adds the API to HAL along with an Android
implementation (and a nop fallback implementation for other
platforms).
Differential Revision: https://phabricator.services.mozilla.com/D186238
natural is defined as (from https://w3c.github.io/screen-orientation/#dfn-natural)
> A computer monitor are commonly naturally landscape-primary, while a mobile
> phones are commonly naturally portrait-primary.
But GeckoView sets `SCREEN_ORIENTATION_UNSPECIFIED` that is unlock orientation.
Like Blink, we should set landscape-primary or portrait-primary (depends on
current monitor).
Differential Revision: https://phabricator.services.mozilla.com/D164436
Now hal uses AR_STATE for screen orientation, so we should move it from
WinUtils.cpp to WinUtils.h for newer Windows 11 SDK.
Also, newer Windows SDK has to set WINVER to WIN8 to use auto rotation API.
Differential Revision: https://phabricator.services.mozilla.com/D163099
Since Windows tablet mode has a orientation lock API, this patch
implements orientation lock backend for Windows tablet mode.
`GetAutoRotationState` API recognizes whether orientation API is supported on
the device. So this fix uses this API to check orientation API capability.
Differential Revision: https://phabricator.services.mozilla.com/D162451
This patch implements hal::SetProcessPriority() on Linux and leverages
it to make it more likely that the parent process and foreground tab
survive an OOM situation, letting Linux' OOM killer reap preallocated
processes and background tabs first when reclaiming memory.
This is achieved by setting the `oom_score_adj` values of said processes
such that they will be killed in this order:
* Preallocated processes will be the first to go, they don't contain
user data and are not visible, so they're a good candidate to free up
memory
* Background tabs will be killed next, we don't generate crash reports
for thoes nor do we inform the user, we just reload the tab, so in
most cases one being killed will only be a small annoyance
* Background tabs playing video come next, but only if they're not also
playing or recording audio
* Finally foreground tabs will be killed as a last resort, background
tabs playing audio or with an active WebRTC session are also
considered to be in the foreground as the user will immediately notice
if they crash
Note that this patch only implements the low-level plumbing. The process
priority manager has not been enabled on Linux yet so that needs to
happen before this actually works.
Differential Revision: https://phabricator.services.mozilla.com/D153466
This prevents copies and avoids the hack we have to avoid this, which
right now is using nsDependent{C,}String.
Non-virtual actors can still use `nsString` if they need to on the
receiving end.
Differential Revision: https://phabricator.services.mozilla.com/D152519
For desktop this should basically have no impact (maybe impacts tab
warming, but if we wanted we could set the priority hint from the tab
switcher the same way we set renderLayers), but Fenix always has
renderLayers as true, effectively, so we were never de-prioritizing the
background tab processes.
Differential Revision: https://phabricator.services.mozilla.com/D145351
For desktop this should basically have no impact (maybe impacts tab
warming, but if we wanted we could set the priority hint from the tab
switcher the same way we set renderLayers), but Fenix always has
renderLayers as true, effectively, so we were never de-prioritizing the
background tab processes.
Differential Revision: https://phabricator.services.mozilla.com/D145351
From https://w3c.github.io/screen-orientation/#apply-an-orientation-lock
> 7.2. Apply an orientation lock
>
> The steps to apply an orientation lock to a Document using orientation are as
> follows:
>
> 1. If the user agent does not support locking the screen orientation, return
> a promise rejected with a "NotSupportedError" DOMException and abort
> these steps.
So if orientation controller delegate isn't set, we should throw
`NotSupportedError`. But, actually, we throws `AbortError`, so this isn't
correct.
To return any DOM error from platform implementation of
`screen.orientation.lock`, I would like to change return value to
`GenericPromise`'s.
Differential Revision: https://phabricator.services.mozilla.com/D137970
Make the ScreenOrientation part of the screen struct, as it should. Stop
using HAL to propagate just screen orientation updates, use the more
general screen manager.
Instead of HAL observers, add a simple observer service notification,
and clean a bunch of the code.
This will simplify bug 1754802 a bit, and is generally simpler.
Shouldn't change behavior. I've tested the events and some common
orientation locking use cases like Youtube, and they behave the same.
Differential Revision: https://phabricator.services.mozilla.com/D138477
This is a mechanical change which was performed by a script based on the
contents of direct_call.py, and then manually checked over to fix
various rewriting bugs caused by my glorified sed script. See the
previous part for more context on the change.
Differential Revision: https://phabricator.services.mozilla.com/D137227
IPC's promise returns resolved promise when IPC connection is successful. So
even if platform implementations such as android returns rejected promise, it
is converted to resolved promise by SandboxHal.cpp unfortunately.
So we should check return value when RecvLockScreenOrientation returns false.
Differential Revision: https://phabricator.services.mozilla.com/D135330
IPC's promise returns resolved promise when IPC connection is successful. So
even if platform implementations such as android returns rejected promise, it
is converted to resolved promise by SandboxHal.cpp unfortunately.
So we should check return value when RecvLockScreenOrientation returns false.
Differential Revision: https://phabricator.services.mozilla.com/D135330
