1283330 - ASSERTION: xmid should be within [x,XMost()] and the wrapped rect should have the same width

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Jesse Ruderman]

Attachment: testcase

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

Comment 1

[Jesse Ruderman]

Attachment: stack

Comment 2

[Lee Salzman [:lsalzman]]

Attachment: take floating point inaccuracy into account for assertions in DecomposeIntoNoRepeatRects

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.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c3c3bc22ff72
take floating point inaccuracy into account for assertions in DecomposeIntoNoRepeatRects. r=nical

Comment 4

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/c3c3bc22ff72