NEW 88571
REGRESSION (r115573): Incorrect rounding in layout of transformed elements (probably -webkit-transform-origin) 
https://bugs.webkit.org/show_bug.cgi?id=88571
Summary REGRESSION (r115573): Incorrect rounding in layout of transformed elements (p...
Tim Horton
Reported 2012-06-07 13:24:29 PDT
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.
Attachments
repro (879 bytes, text/html)
2012-06-07 13:25 PDT, Tim Horton 		no flags
Details
good screenshot (Mac) (20.24 KB, image/png)
2012-06-07 13:25 PDT, Tim Horton 		no flags
Details
bad screenshot (Mac) (20.21 KB, image/png)
2012-06-07 13:25 PDT, Tim Horton 		no flags
Details
FFX rendering (7.11 KB, image/png)
2012-06-07 14:23 PDT, Levi Weintraub 		no flags
Details
fixed repro (892 bytes, text/html)
2012-06-07 15:06 PDT, Tim Horton 		no flags
Details
Repro that works in FFX and WebKit (1.12 KB, text/html)
2012-06-07 15:18 PDT, Levi Weintraub 		no flags
Details
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.
Tim Horton
Comment 1 2012-06-07 13:25:14 PDT
Created attachment 146369 [details] repro
Tim Horton
Comment 2 2012-06-07 13:25:35 PDT
Created attachment 146370 [details] good screenshot (Mac)
Tim Horton
Comment 3 2012-06-07 13:25:54 PDT
Created attachment 146371 [details] bad screenshot (Mac)
Levi Weintraub
Comment 4 2012-06-07 14:23:11 PDT
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.
Levi Weintraub
Comment 5 2012-06-07 14:24:00 PDT
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.
Tim Horton
Comment 6 2012-06-07 14:45:21 PDT
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.
Tim Horton
Comment 7 2012-06-07 14:47:34 PDT
(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.
Tim Horton
Comment 8 2012-06-07 15:06:03 PDT
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.
Levi Weintraub
Comment 9 2012-06-07 15:18:18 PDT
Created attachment 146398 [details] Repro that works in FFX and WebKit Putting the -webkit versions of the transforms back ;)
Levi Weintraub
Comment 10 2012-06-08 12:53:14 PDT
(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.
Levi Weintraub
Comment 11 2012-06-08 14:59:04 PDT
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...
Tim Horton
Comment 12 2012-06-08 15:13:20 PDT
<rdar://problem/11581256>
Simon Fraser (smfr)
Comment 13 2012-06-08 17:14:40 PDT
I think the new behavior is fine.
Note You need to log in before you can comment on or make changes to this bug.