Some gfx drivers (especially on a child process) can open X11 VADisplay instead of a Wayland one which leads
to HW playback failure. As a solution let's create VADisplay explicitly on top of our wayland display connection.
- Load va-api/wayland related libraries only when va-api is enabed by user by widget.wayland-dmabuf-vaapi.enabled
and va-api is generally available (HW acceleration is enabled, dmabuf is available).
- Load vaGetDisplayWl from libva-wayland.so
- Explicitly create VADisplay at CreateVAAPIDeviceContext()
- Use VAAPIDisplayHolder class to release our VADisplay when AVHWDeviceContext is released (by hwctx->free).
Differential Revision: https://phabricator.services.mozilla.com/D71219
Add a gecko pref "gfx.webrender.use-optimized-shaders". If enabled,
then when attempting to compile a webrender shader first look for the
optimized source. If the optimized source is not present, emit a
warning and fall back to the unoptimized source.
Use the optimized source by default in wrench, and add the flag
"--use-unoptimized-shaders" to override this.
Differential Revision: https://phabricator.services.mozilla.com/D70033
Move more shader parsing code to webrender_build, so it can be used
both at runtime and build time.
At build time optimize a set of shaders and feature flag combinations,
using glslopt. Some features are skipped because they are not
supported by the gl version, because the optimizer does not support
them, or because webrender does not need them currently.
Use build-parallel to ensure the optimization is performed in parallel
using the make jobserver. Write the optimized shader source to a
hashmap to be used at runtime, in addition to the unoptimized source.
Differential Revision: https://phabricator.services.mozilla.com/D70032
* For wrench builds, the clang toolchain must now be fetched and be
present in PATH for bindgen to work. When building OSMesa, we must
therefore set `LLVM_CONFIG=no` so that it does not attempt to build
llvmpipe.
* For wrench Mac cross-compiles, we must be careful to expose CFLAGS
and similar variables using the target-specific variable names, so
that host builds do not attempt to use flags intended for the
target. When building OSMesa we must use the generic variable `CC`,
so now we additionally set `HOST_CC`, so that host builds use the
host variable rather than the generic one.
* Similarily, for wrench android builds we must use a fork of
cargo-apk which sets the target-specific variables rather than the
generic ones. Otherwise we would attempt to use the NDK toolchain
for host builds.
Differential Revision: https://phabricator.services.mozilla.com/D70031
For native sanitizer builds, we currently do not pass the linker flags
to cargo, as they were causing crashes in some build scripts. Without
this, however, the linker is unable to find libstdc++. Instead, do
tell cargo to use the linker wrapper, but omit the problematic flags
from MOZ_CARGO_WRAP_LDFLAGS.
Differential Revision: https://phabricator.services.mozilla.com/D70354
This commit firstly moves ResultType and BlockType from WasmOpIter.h to
WasmTypes.h. Many parts of the WebAssembly implementation find
themselves dealing in ResultType so it's natural to define these data
types in a more central place.
Then we add a field to DebugFrame, for the stack results area. This
field is initialized in the baseline compiler prologue, in debug mode.
We also separate the notion of a debug frame with ref-typed cached JS
return values, and a frame with ref-typed result(s). This allows proper
marking of i64 values exposed as BigInt, as well as marking arrays from
multi-result functions of any type.
Finally, we now expose the guts of the ToJSValue code in WasmInstance to
allow the debug trap to synthesize a JS value for a wasm result, even
for multiple value results.
Differential Revision: https://phabricator.services.mozilla.com/D70531
This adds support for instructions that return a new value. In this case the
CacheIRWriter returns a new id of this kind.
Depends on D71520
Differential Revision: https://phabricator.services.mozilla.com/D71521
This adds WrappedPtrOperations and MutableWrappedPtrOperations specialisations for Maybe<T> to all basic Maybe operations to used on Rooted<Maybe<T>>, Handle<Maybe<T>>, etc. I didn't add all of them; in particular I found ptr() would conflict with the Rooted::ptr data member.
This also adds JS::NothingHandleValue for passing Nothing to a Handle<Maybe<Value>>.
Differential Revision: https://phabricator.services.mozilla.com/D71555
- Worker debugger globals gets a client with a null principal
- Ensure globals are created before script loads
- Introduce WorkerGlobalScopeBase to share code
- Transfer ClientSource ownership from WorkerPrivate to worker globals
- Require getting clients from the globals instead of WorkerPrivate with the
exception of getting the reserved client before the non-debugger global is
created
Differential Revision: https://phabricator.services.mozilla.com/D68936
Since we don't support downscaling animated images we'll need something like this even we were to try to request a smaller sized decode.
Differential Revision: https://phabricator.services.mozilla.com/D71523
In the past EGL only supported GLES, not OGL. This has not been true
for a very long time, so lets support OGL context creation in the EGL
backend.
This allows e.g. the Wayland backend to use OGL contexts, which brings
it on par with the X11/GLX backend.
Differential Revision: https://phabricator.services.mozilla.com/D48096
This semicolon workaround is tidier than the `// clang-format off/on` comments and avoids turning off all clang-format checks. The comment also links to clang-format bug 1629756 so future code readers can learn why this extra semicolon exists. And if we find a way to fix this in clang-format, then we can search for this bug number to find and remove these extra semicolons and comments.
Differential Revision: https://phabricator.services.mozilla.com/D71504
Note that it seems unpredictable when we receive the favicon request in the
network monitor, for example, on a Linux machine, the favicon request for a
static link element after the stylesheet link element in
html_cause-test-page.html it happens after the XHR request was received. So
instead of using a static link favicon element, we add a favicon link
dynamically in tests. Unfortunately there is no handy way to tell a favicon
request has done in contents, so we use LinkHandlerParent utility here.
Also note that the favicon request is triggered in FaviconLoader.jsm, which
means the call stack should NOT be shown (bug 1280266). For now, we
intentionally specify the stack and use todo for the case.
Differential Revision: https://phabricator.services.mozilla.com/D70572
Favicon requests happen in 'resource:///modules/FaviconLoader.jsm', so we need
the full URL to match sorted results in tests.
Differential Revision: https://phabricator.services.mozilla.com/D70664
It was required once upon a time to be able to use MozPromise on Workers.
Today a MozPromise work with nsISerialEventTarget and no longer rely on this. It can go.
Differential Revision: https://phabricator.services.mozilla.com/D71442
Glenn Watson
Martin Stransky
Tim Nguyen
Narcis Beleuzu
Kagami Sascha Rosylight
Andrea Marchesini
Jamie Nicol
Dão Gottwald
aarushivij
Brindusan Cristian
Andy Wingo
Benjamin Bouvier
Luca Greco
Tarek Ziadé
Jan de Mooij
Jon Coppeard
Makoto Kato
Paul Adenot
Perry Jiang
Emma Malysz
Timothy Nikkel
Henrik Skupin
Jared Wein
Chris Peterson
Hiroyuki Ikezoe
Jean-Yves Avenard