+++ This bug was initially created as a clone of Bug #1632095 +++

Build ID 20200426094312

Bug #1632095 has been fixed for the case where webrender is enabled only.

Steps to reproduce:

On Linux/wayland with Intel Haswell graphics with
gfx.webrender.enabled=false
widget.wayland-dmabuf-vaapi.enabled=true
widget.wayland-dmabuf-webgl.enabled=true

browse to reddit/youtube and watch a video with available hardware decoding profile (for me: h264 forced with h264ify).

Actual results:

Video is just a green picture
Audio plays fine

LIBVA_DRIVER_NAME=i965 GDK_BACKEND=wayland mozregression --launch 2020-04-26 --pref gfx.webrender.force-disabled:true layers.acceleration.force-enabled:true widget.wayland-dmabuf-vaapi.enabled:true -a https://berlin-ak.ftp.media.ccc.de/congress/2013/mp4/30c3-5605-en-Opening_Event_h264-hq.mp4

Confirmed, but old OpenGL compositor is deprecated. (New features like backdrop filters (bug 1178765) and WebGPU (bug 1629357) are restricted to WebRender. Shouldn't this line be removed, too?)

Does WebRender perform bad on Haswell? (bug 1617148, or force enable by gfx.webrender.all)

You are correct, so basic compositing is the default for my platform (Skylake, but I suppose wayland is disabled because I have HiDPI) but I had layers.acceleration.force-enabled=true.

So I guess I should rather revert to defaults or enable webrender?

I just noticed that bug 1629140 caused a horrible performance regression (2 fps) for WebRender with native Wayland backend on KDE. Gnome is unaffected. Disabling widget.wayland_vsync.enabled fixes it. I will file a new bug about it.

There is a whitelist that controls WebRender rollout: WebRender is enabled by default for qualified systems as long as gfx.webrender.force-disabled hasn't been set to true. On Linux, it is enabled by default for Nightly with Mesa drivers, but for Intel only with max. 4953600 pixels.
It can be force-enabled with gfx.webrender.all (don't forget to restart Nightly). It is enabled if "Compositing" on about:support says "WebRender".
If your GPU ("Device ID" on about:support) is not on the whitelist, please file a bug.
If WebRender is not enabled by default for your screen size, but performs well for you, please file a bug to request enabling it by default for large screens on Intel/Linux. (If it performs bad, you could file a bug as well. :D bug 1620076 and bug 1617498 will help in the future, but bug 1598380 comment 8 could have caused undetected regressions.)

I guess it can be fixed by fiddling with GL compositor shaders but I don't have time to look into it so let's disable it for GL compositor for now.

https://hg.mozilla.org/mozilla-central/rev/a86e1f84755f

FTR: It could well be that we still require the compatibility profile for the GL compositor - maybe we should switch the default to asking for a core profile, only requiring the compat profile where really necessary. Anyhow - Webrender is what we're aiming for, so no reason to invest more into the GL compositor. Devs who want to experiment will usually have a recent GPU and drivers with a compat profile going up to 4.6.

Never had an issue with VAAPI on the layers compositor (Kaby Lake/FreeBSD -CURRENT/Mesa-git iris/Wayfire). Hard disabling this without a pref to force it is too much of a nuclear option IMO ;) But okay, fine, I understand the WR push.

(In reply to greg v [:myfreeweb] from comment #9)

Never had an issue with VAAPI on the layers compositor (Kaby Lake/FreeBSD -CURRENT/Mesa-git iris/Wayfire). Hard disabling this without a pref to force it is too much of a nuclear option IMO ;) But okay, fine, I understand the WR push.

Feel free to provide a patch for it, I just don't want it broken video in FF77 on gl compositor.

(In reply to greg v [:myfreeweb] from comment #9)

nuclear option IMO ;) But okay, fine, I understand the WR push.

Thank you for bug 1620076! :) Yes, everyone with OpenGL 3.1 support should use WebRender and constructively complain if there are problems. Everyone else will get Software WebRender (bug 1601053) at some point.