Closed Bug 1283330 Opened 3 years ago Closed 3 years ago
ASSERTION: xmid should be within [x,XMost()] and the wrapped rect should have the same width
With: user_pref("layers.enable-tiles", false); user_pref("layers.force-active", true); ###!!! ASSERTION: xmid should be within [x,XMost()] and the wrapped rect should have the same width: '!xwrap || (xmid > aRect.x && xmid < aRect.XMost() && FuzzyEqual((xmid - aRect.x) + (aRect.XMost() - xmid), aRect.width))', file gfx/layers/Compositor.cpp, line 374
The test case exacerbates lurking floating-point error bugs in DecomposeIntoNoRepeatRects with large coordinates. The incoming rect has coordinates like (17894492, 0), with width of 1205. But since the coordinates won't fit in the single-precision mantissa, so, for example, aRect.XMost() comes out as 17895696. This error also effects the upper/lower bounds comparisons in the assertion as well as the size validation. The assertion thus needs to be relaxed a bit to accommodate this. I looked at also trying to avoid absolute coordinates here throughout the entire function, but since we're passing down these rectangles to D3D/OpenGL, and they will be turned into absolute coordinates for the underlying vertexes before getting transformed to the final coordinate space, we're going to suffer this error behavior downwind anyway if we don't eat the bullet up here in the layers code. So overall, I decided to just relax the assertion.
Assignee: nobody → lsalzman
Status: NEW → ASSIGNED
Attachment #8774834 - Flags: review?(nical.bugzilla)
Attachment #8774834 - Flags: review?(nical.bugzilla) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/c3c3bc22ff72 take floating point inaccuracy into account for assertions in DecomposeIntoNoRepeatRects. r=nical
You need to log in before you can comment on or make changes to this bug.