This reverts commit 5a05c94949.
Revert "Bug 1966310 - Use weak android symbol instead of dlopen/dlsym for AndroidPerformanceHintManager..cpp r=geckoview-reviewers,m_kato"
This reverts commit 51caedd477.
This reverts commit 8c80ef5139.
Revert "Bug 1966310 - Use weak android symbol instead of dlopen/dlsym for AndroidPerformanceHintManager..cpp r=geckoview-reviewers,m_kato"
This reverts commit 409c852308.
Revert "Bug 1966309 - Use weak android symbol instead of dlopen/dlsym for AndroidSystemFontIterator.cpp r=jnicol"
This reverts commit f130d3a4eb.
Revert "Bug 1966308 - Use weak android symbol instead of dlopen/dlsym for AndroidHardwareBuffer.cpp r=jnicol"
This reverts commit 80505431a5.
Actually, nsIHapticFeedback is called on content process. Then it calls
OS APIs on content process. So if is is isolated process, it doesn't
work or it will crash.
This patch moves haptic feedback implementation to hal to call OS APIs
on chrome process, like vibration.
Differential Revision: https://phabricator.services.mozilla.com/D241929
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
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
Gecko uses the redundant code from nsIScreen to SCreenConfiguration. So we
should add a convert method for newer platform implementations.
Differential Revision: https://phabricator.services.mozilla.com/D134698
Previously, the screenOrientation.lock API was for Fennec and not supported for Fenix and multi-process use. The overall idea is to now allow apps to use the API through a delegate and make asynchronous calls to LockDeviceOrientation. This required replacing the existing code that returned a default false bool to calls that perform the requested orientation change and instead return a promise that contained either an allow or deny value.
Returning a promise instead of a bool involved changing the API calls from the C++ side to Java. The new general control flow of screenOrientation lock follows: an app calls C++ ScreenOrientation.lock() which eventually dispatches LockOrientationTask to resolve the pending orientation promise. Hal.cpp sends an IPC call to the content process and RecvLockScreenOrientation retrieves the current instance of geckoRuntime and calls the java side LockScreenOrientation. Apps must create a delegate and override onOrientationLock to set the requested orientation. In geckoview's testing, this is done with the android API setRequestedOrientation. Once a device orientation change has been triggered, native OnOrientationChange calls to NotifyScreenConfigurationChange, which notifies all observers and dispatches a change event to resolve the pending orientation promise.
Testing:
I used a demo on the GeckoView Example (https://usefulangle.com/demos/105/screen.html) to test locking to landscape orientation. This required a change to the GVE to show the app from recreating the whole thing on orientation change. In the example AndroidManifest xml file, `orientation` prevents restart when orientation changes.
The Junit/Kotlin tests were to verify that the expected orientation delegate was called with the expected new orientation value, in an orientation change, if the new orientation was the same as the current, and if the pre-lock conditions such as being fullscreen were not met.
A static preference `dom.screenorientation.allow-lock` was added to the dom group, since it affects the ui dom) and is currently turned off. C++ can access it through its mirrored variable dom_screenorientation_allow_lock (same name but with underscores). The junit tests turn the preference on and test the lock feature.
Reference:
Orientation constant values:
C++
1 ScreenOrientation_PortraitPrimary); - vertical with button at bottom
2 ScreenOrientation_PortraitSecondary); - vertical with button at top
4 ScreenOrientation_LandscapePrimary); - horizational w button right
8 ScreenOrientation_LandscapeSecondary); - horization button left
16 ScreenOrientation_Default);
Java
1 GeckoScreenOrientation.ScreenOrientation.PORTRAIT_PRIMARY.value
2 GeckoScreenOrientation.ScreenOrientation.PORTRAIT_SECONDARY.value
4 GeckoScreenOrientation.ScreenOrientation.LANDSCAPE_PRIMARY.value
8 GeckoScreenOrientation.ScreenOrientation.LANDSCAPE_SECONDARY.value
Java public API
0 ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE
1 Activitynfo.SCREEN_ORIENTATION_PORTRAIT
Android
1 ORIENTATION_PORTRAIT
2 ORIENTATION_LANDSCAPE
Differential Revision: https://phabricator.services.mozilla.com/D129427
Previously, the screenOrientation.lock API was for Fennec and not supported for Fenix and multi-process use. The overall idea is to now allow apps to use the API through a delegate and make asynchronous calls to LockDeviceOrientation. This required replacing the existing code that returned a default false bool to calls that perform the requested orientation change and instead return a promise that contained either an allow or deny value.
Returning a promise instead of a bool involved changing the API calls from the C++ side to Java. The new general control flow of screenOrientation lock follows: an app calls C++ ScreenOrientation.lock() which eventually dispatches LockOrientationTask to resolve the pending orientation promise. Hal.cpp sends an IPC call to the content process and RecvLockScreenOrientation retrieves the current instance of geckoRuntime and calls the java side LockScreenOrientation. Apps must create a delegate and override onOrientationLock to set the requested orientation. In geckoview's testing, this is done with the android API setRequestedOrientation. Once a device orientation change has been triggered, native OnOrientationChange calls to NotifyScreenConfigurationChange, which notifies all observers and dispatches a change event to resolve the pending orientation promise.
Testing:
I used a demo on the GeckoView Example (https://usefulangle.com/demos/105/screen.html) to test locking to landscape orientation. This required a change to the GVE to show the app from recreating the whole thing on orientation change. In the example AndroidManifest xml file, `orientation` prevents restart when orientation changes.
The Junit/Kotlin tests were to verify that the expected orientation delegate was called with the expected new orientation value, in an orientation change, if the new orientation was the same as the current, and if the pre-lock conditions such as being fullscreen were not met.
A static preference `dom.screenorientation.allow-lock` was added to the dom group, since it affects the ui dom) and is currently turned off. C++ can access it through its mirrored variable dom_screenorientation_allow_lock (same name but with underscores). The junit tests turn the preference on and test the lock feature.
Reference:
Orientation constant values:
C++
1 ScreenOrientation_PortraitPrimary); - vertical with button at bottom
2 ScreenOrientation_PortraitSecondary); - vertical with button at top
4 ScreenOrientation_LandscapePrimary); - horizational w button right
8 ScreenOrientation_LandscapeSecondary); - horization button left
16 ScreenOrientation_Default);
Java
1 GeckoScreenOrientation.ScreenOrientation.PORTRAIT_PRIMARY.value
2 GeckoScreenOrientation.ScreenOrientation.PORTRAIT_SECONDARY.value
4 GeckoScreenOrientation.ScreenOrientation.LANDSCAPE_PRIMARY.value
8 GeckoScreenOrientation.ScreenOrientation.LANDSCAPE_SECONDARY.value
Java public API
0 ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE
1 Activitynfo.SCREEN_ORIENTATION_PORTRAIT
Android
1 ORIENTATION_PORTRAIT
2 ORIENTATION_LANDSCAPE
Differential Revision: https://phabricator.services.mozilla.com/D129427
Previously, the screenOrientation.lock API was for Fennec and not supported for Fenix and multi-process use. The overall idea is to now allow apps to use the API through a delegate and make asynchronous calls to LockDeviceOrientation. This required replacing the existing code that returned a default false bool to calls that perform the requested orientation change and instead return a promise that contained either an allow or deny value.
Returning a promise instead of a bool involved changing the API calls from the C++ side to Java. The new general control flow of screenOrientation lock follows: an app calls C++ ScreenOrientation.lock() which eventually dispatches LockOrientationTask to resolve the pending orientation promise. Hal.cpp sends an IPC call to the content process and RecvLockScreenOrientation retrieves the current instance of geckoRuntime and calls the java side LockScreenOrientation. Apps must create a delegate and override onOrientationLock to set the requested orientation. In geckoview's testing, this is done with the android API setRequestedOrientation. Once a device orientation change has been triggered, native OnOrientationChange calls to NotifyScreenConfigurationChange, which notifies all observers and dispatches a change event to resolve the pending orientation promise.
Testing:
I used a demo on the GeckoView Example (https://usefulangle.com/demos/105/screen.html) to test locking to landscape orientation. This required a change to the GVE to show the app from recreating the whole thing on orientation change. In the example AndroidManifest xml file, `orientation` prevents restart when orientation changes.
The Junit/Kotlin tests were to verify that the expected orientation delegate was called with the expected new orientation value, in an orientation change, if the new orientation was the same as the current, and if the pre-lock conditions such as being fullscreen were not met.
A static preference `dom.screenorientation.allow-lock` was added to the dom group, since it affects the ui dom) and is currently turned off. C++ can access it through its mirrored variable dom_screenorientation_allow_lock (same name but with underscores). The junit tests turn the preference on and test the lock feature.
Reference:
Orientation constant values:
C++
1 ScreenOrientation_PortraitPrimary); - vertical with button at bottom
2 ScreenOrientation_PortraitSecondary); - vertical with button at top
4 ScreenOrientation_LandscapePrimary); - horizational w button right
8 ScreenOrientation_LandscapeSecondary); - horization button left
16 ScreenOrientation_Default);
Java
1 GeckoScreenOrientation.ScreenOrientation.PORTRAIT_PRIMARY.value
2 GeckoScreenOrientation.ScreenOrientation.PORTRAIT_SECONDARY.value
4 GeckoScreenOrientation.ScreenOrientation.LANDSCAPE_PRIMARY.value
8 GeckoScreenOrientation.ScreenOrientation.LANDSCAPE_SECONDARY.value
Java public API
0 ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE
1 Activitynfo.SCREEN_ORIENTATION_PORTRAIT
Android
1 ORIENTATION_PORTRAIT
2 ORIENTATION_LANDSCAPE
Differential Revision: https://phabricator.services.mozilla.com/D129427
As far as I can see, all this does is protect the user from
running some useless code if they manually enable the priority
manager using a pref on an OS that doesn't support it. The
upside of allowing this is that it makes it possible to debug
the priority manager on OSX and Linux with just a pref flip.
Differential Revision: https://phabricator.services.mozilla.com/D114767
This patch is pretty straightforward: it translates Gecko priority levels
into GeckoView priority levels and then sends it up to GV's
`GeckoProcessManager` via JNI.
We do assume that the process is content, but if we try to do that on a
non-content process, it's just a no-op. We can expand this coverage to other
process types later as necessary.
Differential Revision: https://phabricator.services.mozilla.com/D68418
This patch is pretty straightforward: it translates Gecko priority levels
into GeckoView priority levels and then sends it up to GV's
`GeckoProcessManager` via JNI.
We do assume that the process is content, but if we try to do that on a
non-content process, it's just a no-op. We can expand this coverage to other
process types later as necessary.
Differential Revision: https://phabricator.services.mozilla.com/D68418
This patch is pretty straightforward: it translates Gecko priority levels
into GeckoView priority levels and then sends it up to GV's
`GeckoProcessManager` via JNI.
We do assume that the process is content, but if we try to do that on a
non-content process, it's just a no-op. We can expand this coverage to other
process types later as necessary.
Differential Revision: https://phabricator.services.mozilla.com/D68418
This patch is pretty straightforward: it translates Gecko priority levels
into GeckoView priority levels and then sends it up to GV's
`GeckoProcessManager` via JNI.
We do assume that the process is content, but if we try to do that on a
non-content process, it's just a no-op. We can expand this coverage to other
process types later as necessary.
Differential Revision: https://phabricator.services.mozilla.com/D68418
Sylvestre Ledru