1507789 - KDE without compositing/Nvidia: Changing window size when a spin animation is running causes the window to flicker in black

Status: RESOLVED INACTIVE

(Core :: Graphics: WebRender, defect, P3)

Description

[Darkspirit]

Attachment: 2018-11-16_14-27-58.mp4

GTX1060, KDE, Xorg, Debian Testing
MacOS seems to be unaffected.

STR: Open https://dev.terrax.net/ (IPv6-only) and change window size.

last good: Slow spin animation when changing window size.
first bad: Black flickering window content when changing window size. The problem does not happen if I remove the animated loading circle from the website.

mozregression --good 2018-10-01 --bad 2018-11-16 --pref gfx.webrender.all:true -a https://dev.terrax.net/
> 10:40.57 INFO: Last good revision: 5c8a070fcfe8691f7c6344bd7091b5a6a41a0739
> 10:40.57 INFO: First bad revision: 7cbf19248394a63dbbdb707d31e8b265c8a5aca3
> 10:40.57 INFO: Pushlog:
> https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5c8a070fcfe8691f7c6344bd7091b5a6a41a0739&tochange=7cbf19248394a63dbbdb707d31e8b265c8a5aca3

> 7cbf19248394	Jeff Muizelaar — Bug 1498650. Update Cargo lockfiles and re-vendor rust dependencies
> 08f77e821f09	Jeff Muizelaar — Bug 1498650. Update webrender to commit 5adc86c19cbef6697975ea078fa0d10635e5d660

= https://github.com/servo/webrender/pull/3195

Screencast:
last good (left): mozregression --repo mozilla-inbound --launch 5c8a070fcfe8691f7c6344bd7091b5a6a41a0739 --pref gfx.webrender.all:true -a https://dev.terrax.net/
first bad (right): mozregression --repo mozilla-inbound --launch 7cbf19248394a63dbbdb707d31e8b265c8a5aca3 --pref gfx.webrender.all:true -a https://dev.terrax.net/

Comment 1

[Darkspirit]

Reproducible on Win7, but only with ANGLE disabled. Win10 seems to be fine.

Comment 2

[Darkspirit]

Linux + Win7 without ANGLE: The window could flicker black in rare cases already before, but now it's guaranteed to flicker.

Comment 3

[Robert Mader [:rmader]]

Jan, is this still valid?

Comment 4

[Darkspirit]

(In reply to Robert Mader [:rmader] from comment #3)

Jan, is this still valid?

KDE with disabled compositor, Ubuntu 21.04, GTX 1060, Nvidia driver 470.63.01
Yes, still reproducible.
mozregression --launch 2021-09-21 --pref gfx.webrender.all:true gfx.x11-egl.force-disabled:true -a https://codepen.io/teerapuch/pen/vLJXeR

From the regressing pull request:
https://github.com/servo/webrender/pull/3195/files (bug 1496168)

Invalidate render targets when returning them to the pool.
This allows the driver to avoid preserving the old contents we don't
care about.

// Note: The invalidate extension may not be supported, in which
// case this is a no-op. That's ok though, because it's just a
// hint.

/// Transfers ownership of a render target back to the pool.

In bug 1723323 the window can also become partially black.
Maybe the rendered content is thrown away too soon?

In bug 1678804 the top-left quarter of an extension panel shows junk. Could it be related?

Comment 5

[Darkspirit]

Back then, bug 1496168 caused another regression:
bug 1499785 == https://github.com/servo/webrender/pull/3195#issuecomment-430746224

@bholley @kvark any ideas off the top of your head why this PR would result in all the glyphs and images turning into black rectangles on Android? https://bugzilla.mozilla.org/show_bug.cgi?id=1499785

That Android bug was fixed by https://github.com/servo/webrender/pull/3239.

We recently changed to use the glTexStorage* family of functions,
along with sized internal format types, such as BGRA8. Unfortunately,
the GL_EXT_texture_format_BGRA8888 extension does not provide BGRA8 as
a valid format unless the GL_EXT_texture_storage extension is also
available, which is not usually the case on GLES3 as glTexStorage*
are built in.

Unfortunately this means we must fall back to using glTexImage* rather
than glTexStorage* when dealing with BGRA data. Longer term it will
make sense to ensure the provided data is in RGBA format, as the
benifits of immutable storage are desirable.

Comment 6

[Robert Mader [:rmader]]

Hi, can this bug be closed?