See attached reduction and good/bad screenshots. There are two divs, one without any transformation, and one with itself and its parent transformed a total of 360 degrees, theoretically around the center of a circle that should cause it to overlap the non-transformed one. I've colored the rects; before 115573, they overlapped completely, and all you can see is green. After 115573, they do not overlap, and there is red visible. The problem is amplified significantly if subpixel layout is disabled, but it occurs in both states. I have also amplified the issue by adding a scale to the <body>, however, one should note that this is not actually necessary -- ~1px rounding issues occur with -webkit-transform-origin without that scale.
Created attachment 146369 [details] repro
Created attachment 146370 [details] good screenshot (Mac)
Created attachment 146371 [details] bad screenshot (Mac)
Created attachment 146390 [details] FFX rendering Recreating the test case for FFX (replace -webkit with -moz) results in a rendering with red showing. It doesn't look like the math actually does line these boxes up on top of each other.
I should mention that with sub-pixel, our rendering looks pretty close to FFX's (but not identical). I don't believe there should be a gap between the boxes.
Opera agrees with the new rendering (WebKit with subpixel on/Firefox) as well. I'll have to draw some pictures and see what's up.
(In reply to comment #6) > Opera agrees with the new rendering (WebKit with subpixel on/Firefox) as well. I'll have to draw some pictures and see what's up. >left: 50%; I think this is the problem.
Created attachment 146396 [details] fixed repro (In reply to comment #7) > (In reply to comment #6) > > Opera agrees with the new rendering (WebKit with subpixel on/Firefox) as well. I'll have to draw some pictures and see what's up. > > >left: 50%; > > I think this is the problem. Oh, actually, I over-reduced. The original had a "margin-left: -0.05em;" on .container > div, which is critical to this working right. Notice that now, Firefox and Opera agree with pre-115573, and Chrome Canary is very close, but post-115573 Mac Safari (i.e. WebKit ToT with subpixel layout disabled) is still horribly broken (in the same way as before). Attaching a new reduction.
Created attachment 146398 [details] Repro that works in FFX and WebKit Putting the -webkit versions of the transforms back ;)
(In reply to comment #9) > Created an attachment (id=146398) [details] > Repro that works in FFX and WebKit > > Putting the -webkit versions of the transforms back ;) In the sub-pixel case, our issue is that we pixel snap prior to applying transforms. When we have transforms that aren't integer translates, we shouldn't pixel snap, since ultimately we won't be aligning to pixels anyways. Removing the call to pixel snap in paintFillLayerExtended causes us to pass this test with sub-pixel enabled. I'll diagnose the integral case as well.
I think smfr is the best to comment on this, but quite simply we're applying transforms with float precision post 115573, whereas we used to stair step by whole pixel values. Previously, the 0.05em -webkit-transform-origin put on the rotated div would be floored to zero. Putting zero for that value into ToT yields the correct result. Now we carry that value forward. We can floor the value before applying transforms when sub-pixel is turned off if that's the behavior you want, but I'll leave that up to the folks that spend more time thinking about transforms in WebKit...
<rdar://problem/11581256>
I think the new behavior is fine.