Bug 97247 – [chromium] REGRESSION Boundaries with alpha have wrong widths when div rotated and offset to non-integer coordinates

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[Emil A Eklund]

The following draws two divs. Both are rotated by 45°, are offset to non-integer pixel coordinates and have 1px wide borders. The first div's border color is black, the second has an alpha of 0.99 (almost black):

data:text/html,<div style="position:absolute; left: 30.5px; top:30.3px; width: 30px; height: 30px; border: 1px solid rgba(0, 0, 0, 1.00); -webkit-transform: rotate(45deg);"></div><div style="position:absolute; left: 30.5px; top:90.3px; width: 30px; height: 30px; border: 1px solid rgba(0, 0, 0, 0.99); -webkit-transform: rotate(45deg);"></div>

On Chrome 22, the two divs look identical.

On Chrome 23, the second div has incorrect boundary widths: The top left boundary is 2px wide, the bottom right boundary is completely invisible.

Downstream chromium bug: http://code.google.com/p/chromium/issues/detail?id=148734

[Emil A Eklund]

Created attachment 164963 [details]
Patch

[Emil A Eklund]

I'm not entirely convinced that this approach is correct so I'd appreciate input from someone (levi) familiar with the logic.

[Levi Weintraub]

Comment on attachment 164963 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=164963&action=review

> Source/WebCore/rendering/RenderLayer.cpp:3048
> +        // Accumulate and account for sub-pixel rounding to ensure that we round in the right direction.

This would probably make more sense in a static inline function with a descriptive name.

> Source/WebCore/rendering/RenderLayer.cpp:3050
> +        LayoutUnit adjustedWidth = (subPixelAccumulation.width() + (delta.x() - roundedDelta.x())).abs();
> +        LayoutUnit adjustedHeight = (subPixelAccumulation.height() + (delta.y() - roundedDelta.y())).abs();

I don't like the named adjustedWidth/Height.

Why are we taking the absolute value?

> Source/WebCore/rendering/RenderLayer.cpp:3054
> +        while (adjustedWidth > 1)
> +            adjustedWidth -= 1;
> +        while (adjustedHeight > 1)
> +            adjustedHeight -= 1;

I can understand how this got over 1, but it should never be 2 or more. abs(subPixelAccumulation) is between 0 and 1, and abs(delta - roundedDelta) should be  <= 0.5. An assertion of this fact would be good. I don't like these while loops at all.

[Levi Weintraub]

(In reply to comment #2)
> I'm not entirely convinced that this approach is correct so I'd appreciate input from someone (levi) familiar with the logic.

FWIW, this is definitely the right approach except those while loops :)

[Emil A Eklund]

Created attachment 165012 [details]
Patch

[Build Bot]

Comment on attachment 165012 [details]
Patch

Attachment 165012 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/13916345

[Emil A Eklund]

Created attachment 165020 [details]
Patch

[Levi Weintraub]

Comment on attachment 165020 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=165020&action=review

> Source/WebCore/rendering/RenderLayer.cpp:2979
> +static inline LayoutSize adjustSubPixelAccumulation(LayoutSize subPixelAccumulation, LayoutSize roundingAdjustment)

We talked in person about finding a better name for this. Otherwise this looks good.

[Levi Weintraub]

Comment on attachment 165020 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=165020&action=review

> Source/WebCore/rendering/RenderLayer.cpp:2982
> +    LayoutUnit w = (subPixelAccumulation.width() + roundingAdjustment.width()).abs();
> +    LayoutUnit h = (subPixelAccumulation.height() + roundingAdjustment.height()).abs();

Also, we should assert that the abs(w and h) is less than 2 or simply that the final results are less than 1.

[Emil A Eklund]

Created attachment 165217 [details]
Patch

[Bartosz Fabianowski]

Pinging this bug.

We are launching a feature in Chrome 24 that uses this kind of rotated div. It would be nice to get this fixed to avoid the visual glitch.

It seems that there is a patch that got stranded in review?

[Emil A Eklund]

Comment on attachment 165217 [details]
Patch

There have been quite a few changes to the relevant part of the code since this patch was posted. Marking as obsolete for now but will try to post a new one in the next couple of days.

[Emil A Eklund]

This was fixed by r142638.

[Levi Weintraub]

Fantabulous!