Intermittent reftest failure in pixel_snapping_border_a.html

[jdm]

---- pixel_snapping_border_a.html != pixel_snapping_border_ref.html stdout ----
    thread 'pixel_snapping_border_a.html != pixel_snapping_border_ref.html' panicked at 'assertion failed: `(left == right)` (left: `1600`, right: `1280`)', ../../tests/reftest.rs:323

[mbrubeck]

(left:1600, right:1280) means that one image was 1600 pixels wide, while the other was 1280 pixels wide. If both correctly used --device-pixel-ratio 2 as set in the manifest for this test, this means that one was rendered with a viewport of 800px and the other 640px.

Servo's default window size is 800px as set in util::opts::default_ops, but compositor::headless::NullCompositor::create resizes the window to 640px. Perhaps there's a race condition that causes the screenshot to sometimes be taken before this resize and sometimes after.

[jdm]

Now we get:

---- pixel_snapping_border_a.html != pixel_snapping_border_ref.html stdout ----
    thread 'pixel_snapping_border_a.html != pixel_snapping_border_ref.html' panicked at 'assertion failed: `(left == right)` (left: `864`, right: `863`)', ../../tests/reftest.rs:344

So the heights differ by one pixel now??

[mbrubeck]

I have no idea where a height of 863 or 864 is coming from. The default window height is 600px and this test sets a 2× scale factor, which should result in a height of 1200 pixels.

Possibly relevant? 864 = 600 × 1.44 exactly.

[mbrubeck]

These failures are all in mac-dev-ref-unit, but they happen on both Mac test machines (servo-mac1 and servo-mac2).

[glennw]

Mac seems to use some kind of heuristic to determine where to place new windows. When running several tests in parallel, they can be opened in a way that they are partially off screen.

Previously this would result in a similar bug - the output image would be the clipped size. I thought this was fixed by using an FBO to render reftest output on mac. But perhaps this has changed, or perhaps it uses the window size to write the FBO image output, or something like that?

[mbrubeck]

Presumably this test triggers the problem just because its window is so big. Perhaps we can give it a custom window size that's smaller, as a workaround.

[glennw]

Yep - I suspect that's why this test is triggering the bug more often, and that would probably work around it. We should fix the underlying problem too though :)

[jdm]

initialize_png is given the window width and height and uses them for tex_image_2d.

[glennw]

I guess the question is what are the value of window width/height in these instances? I would have thought it would be the requested size rather than clipped to the screen.

[jdm]

From the builder in a failing instance:

w: 1280, h: 847
w: 1280, h: 850

[jdm]

In particular, we initialize our window_size member with window.framebuffer_size(), and our glutin port has this:

    fn framebuffer_size(&self) -> TypedSize2D<DevicePixel, u32> {
        let scale_factor = self.window.hidpi_factor() as u32;
        let (width, height) = self.window.get_inner_size().unwrap();
        Size2D::typed(width * scale_factor, height * scale_factor)
    }

[metajack]

What I can recall from setting up the mac builders is that if a window appears partially offscreen, the framebuffer created for the window is clipped to the actual visible area. To address this, we set the screen size large enough that ref tests wouldn't appear offscreen.

Lars has upgraded the mac builders a few times, so vncing into the mac builders and ensuring they have a large resolution is probably a worthwhile sanity check. I think we only do offscreen rendering on linux.

[jdm]

Hasn't been seen in months, not disabled => close.