Bug 140535 - Border-radius clip of non-stacking composited descendant doesn't work
Summary: Border-radius clip of non-stacking composited descendant doesn't work
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Compositing (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Simon Fraser (smfr)
URL:
Keywords: InRadar
: 216065 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-01-15 20:23 PST by Simon Fraser (smfr)
Modified: 2021-09-22 13:22 PDT (History)
7 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Fraser (smfr) 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.
Comment 1 Simon Fraser (smfr) 2015-01-15 22:03:52 PST
I have a fix for this.
Comment 2 Simon Fraser (smfr) 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.
Comment 3 Byungseon Shin 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.
Comment 4 Russell Bicknell 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.
Comment 5 Simon Fraser (smfr) 2016-07-14 15:27:47 PDT
Please file that issue in a new bug.
Comment 6 Russell Bicknell 2016-07-14 16:36:02 PDT
Filed as 159794.
Comment 7 Radar WebKit Bug Importer 2020-08-19 11:22:18 PDT
<rdar://problem/67414831>
Comment 8 Simon Fraser (smfr) 2021-09-22 12:05:51 PDT
*** Bug 216065 has been marked as a duplicate of this bug. ***