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
Created attachment 164963 [details] Patch
I'm not entirely convinced that this approach is correct so I'd appreciate input from someone (levi) familiar with the logic.
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.
(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 :)
Created attachment 165012 [details] Patch
Comment on attachment 165012 [details] Patch Attachment 165012 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/13916345
Created attachment 165020 [details] Patch
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.
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.
Created attachment 165217 [details] Patch
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?
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.
This was fixed by r142638.
Fantabulous!