The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
There is a crash in glFenceSync (used to recycle PBOs when uploading
textures) affecting several PowerVR GPUs. Block webrender on the known
bad combinations of GPU and driver versions.
Differential Revision: https://phabricator.services.mozilla.com/D148638
This removes a bunch of custom code from GfxInfo to obtain screen
information, and instead collects that screen information in
ScreenManager.
This, apart of removing duplicated code, has the extra benefit of
reporting multi-monitor information on GTK (and potentially in the
future reporting scale and refresh rate properly as well, I've kept the
telemetry as it was on that regard).
Differential Revision: https://phabricator.services.mozilla.com/D145178
This removes a bunch of custom code from GfxInfo to obtain screen
information, and instead collects that screen information in
ScreenManager.
This, apart of removing duplicated code, has the extra benefit of
reporting multi-monitor information on GTK (and potentially in the
future reporting scale and refresh rate properly as well, I've kept the
telemetry as it was on that regard).
Differential Revision: https://phabricator.services.mozilla.com/D145178
For example, the SDK class android.media.MediaDrm$KeyStatus will now
be defined as MediaDrm::KeyStatus rather than just KeyStatus.
Not only does this avoid polluting the top-level namespace, but it
also avoids a bug where invalid type names were generated if the
nested class contains a method with a parameter or return of the outer
class' type.
Differential Revision: https://phabricator.services.mozilla.com/D143043
On Android version 12, it appears as if the EGL context does not
correctly get detached from a Surface when its process dies. This
means that subsequent attempts to create an EGL context fail, meaning
we cannot render anything.
This results in a completely unusable browser following a GPU process
crash, which is worse than the alternative of a parent process crash.
Block the GPU process on Android 12 and above until we have found a
workaround.
Differential Revision: https://phabricator.services.mozilla.com/D142452
As historical reason, AndroidBridge has a lot of JNI wrappers. But we have
auto-generation JNI wrappers now, so it is unnecessary to keep wrappers in
AndroidBridge for GfxInfo.
So I would like to remove AndroidBridge dependencies from GfxInfo.
Differential Revision: https://phabricator.services.mozilla.com/D135324
Due to bug 1742986 and bug 1717863 we are blocking webrender on
Android devices PowerVR Rogue G6110 GPUs. These devices will use
software webrender instead.
Differential Revision: https://phabricator.services.mozilla.com/D132170
While webrender has been shipping for a long time on other Adreno 5xx
devices, we had disabled it on Adreno 505 and 506 due to frequent
crashes during shader compilation. This crash has now been fixed, so
we can ship webrender to these devices.
Depends on D117427
Differential Revision: https://phabricator.services.mozilla.com/D117428
Webrender had previously been disabled on Adreno 3xx devices running
Android 9 due to a rendering issue caused by a driver bug. (See bug
1712148) The issue has now been identified and a workaround put in
place, so we can re-enable webrender.
Depends on D117033
Differential Revision: https://phabricator.services.mozilla.com/D117034
Due to a report of flashing black rectangles on an Adreno 308 device
running Android 9. As a precaution disable webrender for android 9 and
later for all Adreno 3xx GPUs.
Differential Revision: https://phabricator.services.mozilla.com/D115622
We encounter frequent crashes in glLinkProgram on some Adreno
devices. This is likely due to a driver bug, but we have been unable
to figure out the exact cause and work around it.
According to the crash data, this bug appears to affect Adreno 505 and
506 devices running Android 9 only. Disable webrender on these devices
in order to avoid the crash.
Depends on D114949
Differential Revision: https://phabricator.services.mozilla.com/D114950
Previously we had disabled optimized shaders on Mali-T devices running
Android versions up to 5.1, due to broken rendering. We have now had a
report of the same issue on Android 7.1. As a precaution, disable
optimized shaders for all Mali-T devices regardless of android version.
Differential Revision: https://phabricator.services.mozilla.com/D113913
An earlier patch in this bug disabled webrender on these devices due
to reports of broken rendering. Now that the cause of the broken
rendering has been worked around, we can re-enable webrender.
Depends on D113313
Differential Revision: https://phabricator.services.mozilla.com/D113319
Previously in bug 1689064 we disabled our usage of optimized shaders
to work around a driver bug affecting Mali-T6xx devices. It now
appears this bug affects Mali-T7xx and T8xx devices too, only on
Android versions 5.1 or below. This patch disables shader optimization
for all Mali-T devices when the Android version is 5.1 or below.
Differential Revision: https://phabricator.services.mozilla.com/D113313
There appears to be a driver issue causing the browser to be unusable
on such devices. Disable webrender until we diagnose the issue and
find a workaround.
Differential Revision: https://phabricator.services.mozilla.com/D113296
Running webrender on PowerVR Rogue devices results in some images
being rendered with swapped R and B channels. This is because we use
texture swizzling for images in the shared texture cache, and
presumably the driver has a buggy implementation. This patch disables
texture swizzling on all PowerVR Rogue devices as a precaution.
It also ensures that we always use BGRA format textures in cases where
texture swizzling is unsupported, otherwise we encounter GL errors
when attempting to upload BGRA data to RGBA format textures, as GLES
does not support format conversion during upload. Furthermore, we make
it so that using RGBA+glTexStorage+swizzling is preferred to
BGRA+glTexImage in cases where swizzling is actually supported, as we
generally want to prefer glTexStorage to glTexImage.
Lastly, in cases where neither BGRA or swizzling are supported, rather
than attempting to upload BGRA data to RGBA textures (which will
result in a GL error) we pretend the BGRA data is RGBA. This will
result in the channels being swapped when rendering, but that is
preferable to the alternative of images not being uploaded at
all. This configuration shouldn't actually exist in the wild anyway.
Differential Revision: https://phabricator.services.mozilla.com/D111840
Loading cached shaders with glProgramBinary fails consistently for all
but the most trivial of our shaders on Adreno 3xx, so caching and
attempting to load them is a waste of time. Chromium and other
projects also appear to have disabled their shader caches on Adreno
3xx due to bugs.
This patch moves the gfx.webrender.program-binary-disk pref
declaration from all.js to StaticPrefList.yaml. Rather than directly
using the value of the pref to decide whether to create the shader
cache, we now initialize a Feature in gfxConfigManager with a default
value from the pref and then configure it from the blocklist. On
Android we block the feature on Adreno 3xx devices. The pref remains
true by default on Android and Windows, and false by default on Linux
and Macos.
Differential Revision: https://phabricator.services.mozilla.com/D111427
Thanks to the previous patch in this series we can now play video
using the non-essl3 GL_OES_EGL_image_external extension, therefore we
no longer require the essl3 version.
It is assumed that all android devices support
GL_OES_EGL_image_external (non-essl3). Even if that is not the case,
webrender is no worse off than layers in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D108909
On some Mali devices we have encountered driver crashes caused by
calling textureSize(samplerExternalOES) in a shader without also
potentially sampling from the texture in the shader. ARM's suggested
workaround was to trick the driver in to thinking that the texture may
be sampled from (ie by sampling in a branch which is never dynamically
taken).
This is done by checking the value of a dummy uniform, and sampling
the texture if the value is non-default. Using a constant expression
did not work because the compiler would optimize the condition (and
therefore the sample) away.
Also re-enable webrender on Mali-72 and G76 devices, as it was blocked
due to this bug.
Differential Revision: https://phabricator.services.mozilla.com/D105493
Note that quite a few Mali-Txxx devices still won't get webrender, due
to lack of GL_OES_EGL_image_external_essl3 support. Bug 1507074 tracks
lifting this requirement.
Depends on D105338
Differential Revision: https://phabricator.services.mozilla.com/D105339
Webrender has been enabled for most Adreno 5xx and 6xx devices for a
while now, but 505 and 506 were held back due to bug 1609191. We were
seeing a moderate number of crashes during what we suspected was
shader compilation.
The crashes on 505 and 506 have all but disappeared. Additionally,
after shipping to the wider release audience we saw the same crashes
on other 5xx devices, not just 505 and 506, but the numbers were never
so high as to be worrying. So we are safe to ship to 505 and 506 as
well.
Depends on D105337
Differential Revision: https://phabricator.services.mozilla.com/D105338
In bug 1688017 we blocked webrender on Mali-G76 devices due to reports
of crashes when playing video. Based on more reports by users and
further investigation of the crash data, it appears that Mali-G72 GPUs
are also affected by the same bug, but only on Android 11 (for both
GPUs). Crashes on other Mali GPUs and earlier android versions do
exist, but in much lower numbers.
Update the block to include G72 as well as G76, but only for Android
11.
Differential Revision: https://phabricator.services.mozilla.com/D105047
Webrender's pre-optimized shaders result in completely broken
rendering on a Huawei MediaPad M2 (Mali-T628). As a precaution,
disable optimized shaders on all Mali-T6xx devices.
Differential Revision: https://phabricator.services.mozilla.com/D104752
Webrender's pre-optimized shaders result in completely broken
rendering on a Huawei MediaPad M2 (Mali-T628). As a precaution,
disable optimized shaders on all Mali-T6xx devices.
Differential Revision: https://phabricator.services.mozilla.com/D104752
Webrender's pre-optimized shaders result in completely broken
rendering on a Huawei MediaPad M2 (Mali-T628). As a precaution,
disable optimized shaders on all Mali-T6xx devices.
Differential Revision: https://phabricator.services.mozilla.com/D104752
Currently webrender requires the extension
GL_OES_EGL_image_external_essl3 to render video. There exist some
older GLES 3 devices which do not support this extension, and
attempting to render video on these devices results in a shader
compilation error and falling back to OpenGL layers.
In bug 1507074 we will implement a long term solution for such
devices, but in the meantime block webrender on devices which do not
support this extension.
Differential Revision: https://phabricator.services.mozilla.com/D104669
Currently webrender requires the extension
GL_OES_EGL_image_external_essl3 to render video. There exist some
older GLES 3 devices which do not support this extension, and
attempting to render video on these devices results in a shader
compilation error and falling back to OpenGL layers.
In bug 1507074 we will implement a long term solution for such
devices, but in the meantime block webrender on devices which do not
support this extension.
Differential Revision: https://phabricator.services.mozilla.com/D104669
