[Webkit-unassigned] [Bug 141653] Huge blur request causes WebKit to treat blur as a no-op

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=141653

--- Comment #2 from Brent Fulgham <bfulgham at webkit.org> ---
In both cases (ToT and safari-600.5-branch), the regions look like the following:

filterBoxRect: (512, 512) of size 3200x3200.
dirtyRect: (0, 0) of size 51200x38400

We move the dirtyRect around a bit based on the blurring dimensions (which are quite big) leaving us with:
rectForRepaint: (-1024868352, -1024868352) of size 2049787904x2049775104

So far, both branches look the same. But in ToT we do our layout math using subpixel logic. And this makes a big difference.

We check the intersection of the ‘rectForRepaint’ and the filterBoxRect. If there is no intersection, we do nothing.

void LayoutRect::intersect(const LayoutRect& other)
{
    LayoutPoint newLocation(std::max(x(), other.x()), std::max(y(), other.y()));
    LayoutPoint newMaxPoint(std::min(maxX(), other.maxX()), std::min(maxY(), other.maxY()));

    // Return a clean empty rectangle for non-intersecting cases.
    if (newLocation.x() >= newMaxPoint.x() || newLocation.y() >= newMaxPoint.y()) {
        newLocation = LayoutPoint(0, 0);
        newMaxPoint = LayoutPoint(0, 0);
    }

    m_location = newLocation;
    m_size = newMaxPoint - newLocation;
}

The above code is the same for both branches, but the LayoutPoint class is different. This gives us the following resulting points:

ToT:
newLocation    (2147483647, 2147483647)
newMaxPoint    (3776, 3712)

Since the location is way past the max point, we throw out everything and move on.

safari-600.5-branch:
newLocation    (512, 512)
newMaxPoint    (3712, 3712)

Uh, oh! Now we have work to do.

These values differ because in safari-600.5-branch, the x() return value is a signed integer value for the purpose of comparison. In ToT, it is unsigned so we get these huge values (in this crazy case) that result in no intersection.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150216/a6b1c189/attachment-0002.html>