[windows] Loading layout/reftests/bugs/718521.html with WR enabled shows a blank page

RESOLVED FIXED

Status

()

Core
Graphics: WebRender
P3
normal
RESOLVED FIXED
11 months ago
10 months ago

People

(Reporter: kats, Unassigned)

Tracking

(Blocks: 1 bug)

Other Branch
x86_64
Windows
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [gfx-noted])

On Windows, if you start firefox with WR enabled and load layout/reftests/bugs/718521.html it shows a blank page. On other platforms it correctly shows the three canvases.

As if this isn't bad enough, loading other pages after this results in wonky behaviour. For example, load the 718521-ref.html file right after and move the mouse around. The content area flickers, it looks as though every other frame is blank, and we alternate between showing these blank frames and the correct rendering of the three divs.
After I updated to latest m-c tip I don't see the flickering anymore, but loading the 718521-ref.html file after the 718521.html file shows solid blank. If I load the -ref file first it renders correctly. Definitely still a problem with how 718521.html gets processed through WR.
I spent some time wrapping my head around the relevant WR code and I think I verified that one half of the code is working fine - the half where the image key and image requests are processed by WR, the external image data is supplied to WR by gecko, and the image data is put into the texture via texSubImage2d. I haven't yet verified the part where it is pushed to the screen.

Comment 3

11 months ago
I also reproduce the problem locally. When the problem happened, framebuffer validity check in attachmentsHaveSameDimensions() was failed.

The following is a callstack.

 libGLESv2.dll!gl::FramebufferState::attachmentsHaveSameDimensions() Line 196
 libGLESv2.dll!rx::FramebufferD3D::checkStatus() Line 317
 libGLESv2.dll!gl::Framebuffer::checkStatusImpl() Line 710
 libGLESv2.dll!gl::Framebuffer::checkStatus() Line 482
 libGLESv2.dll!gl::ValidateClear() Line 1920
 libGLESv2.dll!gl::Clear(unsigned int mask=0x00004000) Line 295
 libGLESv2.dll!glClear(unsigned int mask=0x00004000) Line 97
 xul.dll!gleam::ffi_gles::Gles2::Clear(unsigned int self={...}) Line 1525
 xul.dll!gleam::gl::{{impl}}::clear() Line 1228
 xul.dll!webrender::device::Device::clear_target_rect() Line 2009
 xul.dll!webrender::renderer::Renderer::draw_alpha_target() Line 1961
 xul.dll!webrender::renderer::Renderer::draw_tile_frame() Line 2209
 xul.dll!webrender::renderer::{{impl}}::render::{{closure}}(closure) Line 1399
 xul.dll!webrender::profiler::TimeProfileCounter::profile<webrender::device::FrameId,closure>(closure self={...}) Line 154
 xul.dll!webrender::renderer::Renderer::render(euclid::size::TypedSize2D<u32, webrender_api::units::DevicePixel> self={...}) Line 1377
 xul.dll!webrender_bindings::bindings::wr_renderer_render() Line 728
 xul.dll!mozilla::wr::RendererOGL::Render() Line 132
 xul.dll!mozilla::wr::RenderThread::UpdateAndRender(WrWindowId aWindowId={...}) Line 222
 xul.dll!mozilla::wr::RenderThread::NewFrameReady(WrWindowId aWindowId={...}) Line 170

Comment 4

11 months ago
The callstack in Comment3 was same to Bug 1372083 Comment4. From it, it might be caused by same reason of Bug 1372083.

Updated

11 months ago
See Also: → bug 1372083
Thanks!

Comment 6

10 months ago
Confirmed that the problem was addressed with https://github.com/servo/webrender/issues/1470.
Status: NEW → RESOLVED
Last Resolved: 10 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.