mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-11-27 06:43:32 +00:00
Read-only Git mirror of the Mercurial gecko repositories at https://hg.mozilla.org. How to contribute: https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html
0c43a18e35
On Android, SurfaceTextures provide a transform that should be applied to texture coordinates when sampling from the texture. Usually this is simply a y-flip, but sometimes it includes a scale and slight translation, eg when the video frame is contained within a larger texture. Previously we ignored this transform but performed a y-flip, meaning we rendered correctly most of the time, but not all of the time. Our first attempt to fix this was in bug 1731980. When rendering as a compositor surface with RenderCompositorOGLSWGL, we supplied the transform to CompositorOGL's shaders, which correctly fixed the bug for this rendering path. However, the attempted fix for hardware webrender in fact made things worse. As UV coordinates are supplied to webrender unnormalized, then the shaders normalize them by dividing by the actual texture size, this effectively handled the scale component of the transform. (Though not quite scaling by the correct amount, and ignoring the translation component, sometimes resulting in a pixel-wide green seam being visible at the video's edges.) When we additionally applied the transformation to the coordinates, it resulted in the scale being applied twice, and the video being rendered too far zoomed in. To make matters worse, when we received subsequent bug reports of incorrect rendering on various devices we mistakenly assumed that the devices must be buggy, rather than our code being incorrect. We therefore reverted to ignoring the transform on these devices, thereby breaking the software webrender path again. Additionally, on devices without GL_OES_EGL_image_external_essl3 support, we must sample from the SurfaceTexture using an ESSL1 shader. This means we do not have access to the correct texture size, meaning we cannot correctly normalize the UV coordinates. This results in the video being rendered too far zoomed out. And in the non-compositor-surface software webrender path, we were accidentally downscaling the texture when reading back into a CPU buffer, resulting in the video being rendered at the correct zoom, but being very blurry. This patch aims to handle the transform correctly, in all rendering paths, hopefully once and for all. For hardware webrender, we now supply the texture coordinates to webrender already normalized, using the functionality added in the previous patch. This avoids the shaders scaling the coordinates again, or using an incorrect texture size to do so. For RenderCompositorOGLSWGL, we continue to apply the transform using CompositorOGL's shaders. In the non-compositor-surface software webrender path, we make GLReadPixelsHelper apply the transform when reading from the SurfaceTexture in to the CPU buffer. Again using functionality added earlier in this patch series. This avoids downscaling the image. We can then provide the default untransformed and unnormalized UVs to webrender. As a result we can now remove the virtual function RenderTextureHost::GetUvCoords(), added in bug 1731980, as it no longer serves any purpose: we no longer want to share the implementation between RenderAndroidSurfaceTextureHost::Lock and RenderTextureHostSWGL::LockSWGL. Finally, we remove all transform overrides on the devices we mistakenly assumed were buggy. Differential Revision: https://phabricator.services.mozilla.com/D220582 |
||
|---|---|---|
| .cargo | ||
| .github/workflows | ||
| .vscode | ||
| accessible | ||
| browser | ||
| build | ||
| caps | ||
| chrome | ||
| config | ||
| devtools | ||
| docs | ||
| docshell | ||
| dom | ||
| editor | ||
| extensions | ||
| gfx | ||
| gradle/wrapper | ||
| hal | ||
| image | ||
| intl | ||
| ipc | ||
| js | ||
| layout | ||
| media | ||
| memory | ||
| mfbt | ||
| mobile | ||
| modules | ||
| mozglue | ||
| netwerk | ||
| nsprpub | ||
| other-licenses | ||
| parser | ||
| python | ||
| remote | ||
| security | ||
| services | ||
| servo | ||
| startupcache | ||
| storage | ||
| supply-chain | ||
| taskcluster | ||
| testing | ||
| third_party | ||
| toolkit | ||
| tools | ||
| uriloader | ||
| view | ||
| widget | ||
| xpcom | ||
| xpfe/appshell | ||
| .arcconfig | ||
| .babel-eslint.rc.js | ||
| .clang-format | ||
| .clang-format-ignore | ||
| .cron.yml | ||
| .eslintrc-ignores.js | ||
| .eslintrc-rollouts.js | ||
| .eslintrc-test-paths.js | ||
| .eslintrc.js | ||
| .git-blame-ignore-revs | ||
| .gitattributes | ||
| .gitignore | ||
| .hg-annotate-ignore-revs | ||
| .hgignore | ||
| .hgtags | ||
| .lando.ini | ||
| .lldbinit | ||
| .mailmap | ||
| .prettierignore | ||
| .prettierrc.js | ||
| .rstcheck.cfg | ||
| .stylelintignore | ||
| .stylelintrc.js | ||
| .taskcluster.yml | ||
| .trackerignore | ||
| .yamllint | ||
| .ycm_extra_conf.py | ||
| aclocal.m4 | ||
| AUTHORS | ||
| build.gradle | ||
| Cargo.lock | ||
| Cargo.toml | ||
| client.mk | ||
| client.py | ||
| CLOBBER | ||
| configure | ||
| configure.py | ||
| GNUmakefile | ||
| gradle.properties | ||
| gradlew | ||
| gradlew.bat | ||
| LICENSE | ||
| mach | ||
| mach.cmd | ||
| mach.ps1 | ||
| Makefile.in | ||
| mots.yaml | ||
| moz.build | ||
| moz.configure | ||
| mozilla-config.h.in | ||
| old-configure.in | ||
| package-lock.json | ||
| package.json | ||
| pyproject.toml | ||
| README.txt | ||
| settings.gradle | ||
| substitute-local-geckoview.gradle | ||
| test.mozbuild | ||
An explanation of the Firefox Source Code Directory Structure and links to
project pages with documentation can be found at:
https://firefox-source-docs.mozilla.org/contributing/directory_structure.html
For information on how to build Firefox from the source code and create the patch see:
https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html
If you have a question about developing Firefox, and can't find the solution
on https://firefox-source-docs.mozilla.org/, you can try asking your question on Matrix at chat.mozilla.org in `Introduction` (https://chat.mozilla.org/#/room/#introduction:mozilla.org) channel.
Nightly development builds can be downloaded from:
https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/
- or -
https://www.mozilla.org/firefox/channel/desktop/#nightly
Keep in mind that nightly builds, which are used by Firefox developers for
testing, may be buggy.