Bug 140535

Summary: Border-radius clip of non-stacking composited descendant doesn't work
Product: WebKit Reporter: Simon Fraser (smfr) <simon.fraser>
Component: CompositingAssignee: Simon Fraser (smfr) <simon.fraser>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: bicknellr, kandalkar.abhijeet58, karlcow, simon.fraser, sun.shin, thorton, timdream, webkit-bug-importer
Priority: P2 Keywords: BrowserCompat, InRadar
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=216978
https://bugs.webkit.org/show_bug.cgi?id=230636
https://bugs.webkit.org/show_bug.cgi?id=231360
https://bugs.webkit.org/show_bug.cgi?id=238983
https://bugs.webkit.org/show_bug.cgi?id=67950
https://bugs.webkit.org/show_bug.cgi?id=244337
Attachments:
Description Flags
Testcase
none
extra examples w/ exaggerated offsets none

Simon Fraser (smfr)
Reported 2015-01-15 20:23:11 PST
Created attachment 244746 [details] Testcase Attached testcase shows a big blue rectangle on Mac; it should get radius clipping.
Attachments
Testcase (566 bytes, text/html)
2015-01-15 20:23 PST, Simon Fraser (smfr) 		no flags
Details
extra examples w/ exaggerated offsets (2.71 KB, text/html)
2016-07-14 14:48 PDT, Russell Bicknell 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Simon Fraser (smfr)
Comment 1 2015-01-15 22:03:52 PST
I have a fix for this.
Simon Fraser (smfr)
Comment 2 2015-01-15 22:17:44 PST
Actually I take that back. This is the non-stacking context case, where we use m_ancestorClippingLayer, which is going to also need a mask equivalent.
Byungseon(Sun) Shin
Comment 3 2015-01-19 10:37:36 PST
I guess it is came from the Container didn’t participate in overlap detection, so it couldn't clip child layer since later painting order of graphics layer.
Russell Bicknell
Comment 4 2016-07-14 14:48:28 PDT
Created attachment 283687 [details] extra examples w/ exaggerated offsets I found something recently that seems very closely related to this bug: composited descendants are positioned slightly differently than their ancestors. If the ancestor has a non-integer top or left (either set directly or during an animation) the descendant is sometimes positioned up or left by one *device* pixel. Maybe composited elements are aligned with floor and non-composited with normal rounding? In the attached page, the examples labeled "scale3d transform" show both this bug and the positioning thing I mentioned. However, the two cases at the bottom might go against my float vs. normal rounding possibility: If top / left of the parent are integers but a transform applied to it translates it by some non-integer amount, then there isn't any noticeable difference in the positions of the parent and child. If the top / left of the parent are *not* integers, then you can still see the slight offset of the parent and child - even with a zero translate3d transform applied to the parent. Also, if you zoom the page, you'll notice the offsets change but are never larger than one device pixel.
Simon Fraser (smfr)
Comment 5 2016-07-14 15:27:47 PDT
Please file that issue in a new bug.
Russell Bicknell
Comment 6 2016-07-14 16:36:02 PDT
Filed as 159794.
Radar WebKit Bug Importer
Comment 7 2020-08-19 11:22:18 PDT
<rdar://problem/67414831>
Simon Fraser (smfr)
Comment 8 2021-09-22 12:05:51 PDT
*** Bug 216065 has been marked as a duplicate of this bug. ***
Simon Fraser (smfr)
Comment 9 2022-08-31 14:40:14 PDT
*** This bug has been marked as a duplicate of bug 68196 ***
Note You need to log in before you can comment on or make changes to this bug.