1655376 - Rounding or snapping issue when building iframes when device pixel ratio is fractional.

Status: RESOLVED FIXED

(Core :: Graphics: WebRender, defect)

Description

[Glenn Watson [:gw]]

Steps to reproduce:

• Run with WR enabled.
• Set layout.css.devPixelsPerPx to 1.5
• ./mach run about:blank

(note that the window size and device pixel ratio may need to be adjusted, depending on local system, to see the problem).

If I do this, I see the following occur in PushIFrame [1]:
aBounds has y: 111, height: 2008.5
mClipChainLeaf has y: 110.5, height: 2008.5

The clip rect supplied to WR from MergeClipLeaf then has y=111, height=2008 which seems wrong (off by 1 pixel).

The values always match correctly when the device pixel ratio is 1.0, so I guess this is a rounding / snapping issue, but I'm not sure where.

Questions:

• Would we expect the iframe bounds to have a fractional offset and/or height?
• Would we expect the clip chain leaf to have a fraction offset and/or height?
• Any ideas which part of the code might be inconsistent / causing the difference?

[1] https://searchfox.org/mozilla-central/source/gfx/webrender_bindings/WebRenderAPI.cpp#1290

Comment 1

[Glenn Watson [:gw]]

(The clip-chains that items inside that iframe get have a height of 2009)

Comment 2

[Kartikaya Gupta (email:[e-mail])]

Assuming the chrome-process area is the usual 74 CSS pixels tall, it makes sense for the iframe's top to be at y=111 (i.e. 74 * 1.5). And I'm assuming the height is 1339 CSS pixels, producing h=2008.5 layout pixels. So I think the aBounds value is correct, but mClipChainLeaf's y-value seems wrong. MergeClipLeaf takes the intersection of the two, so if we fix mClipChainLeaf to have a y=110 instead of y=110.5 the intersection result should come out correctly.

Would we expect the iframe bounds to have a fractional offset and/or height?

In terms of what is exposed to web content (CSS pixels) I imagine that it should always be integer values (and it is in this case). What it comes out to be in layout pixels internally in Gecko might very well be fractional. Maybe it should be getting rounded somewhere, but evidently it is not, and changing that seems almost orthogonal to this problem.

Would we expect the clip chain leaf to have a fraction offset and/or height?

As with iframe bounds, I think if the value in layout pixels is fractional that should be ok.

Any ideas which part of the code might be inconsistent / causing the difference?

As mentioned above it seems to me from your description that the mClipChainLeaf shouldn't be 110.5. I'm not sure offhand where that is coming from - if you want me to dig further I might be able to do so but probably not until next week. If you can repro with rr though it should be not-too-burdensome to trace this backwards and see why it's coming out wrong. If you get a gecko display list dump from the parent process (layout.display-list.dump-parent=true) that might provide some insight too.

Comment 3

[Glenn Watson [:gw]]

Attachment: Bug 1655376 - Fix early rounding of iframe origin for WR.

WR handles snapping of primitives and clips, and prefers the input
data to be exact floats. This fixes an inconsistency between the
clip and bounds of iframes in WR when there is a fractional
device-pixel ratio set.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/268fe244132f
Fix early rounding of iframe origin for WR. r=kats,aosmond

Comment 5

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/268fe244132f