Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upFast (Unblurred) Shadows Mishandle Clips #1928
Closed
Comments
|
I'm happy to fix this, but I'm not really sure how mutating the clip-scroll-tree is supposed to work. |
|
I think the right answer here might be that we want to adjust the local clip rect on the item only, and leave any clips in the clip-scroll tree as-is. But @gankro is working on some test case(s) that we can use to investigate further. |
|
Another option would be to abandon fast-shadows if internal clips are found, but that's probably too aggressive? |
Gankra
changed the title
|
This was bugzilled: https://bugzilla.mozilla.org/show_bug.cgi?id=1414125 |
bors-servo
added a commit
that referenced
this issue
Jan 17, 2018
… r=Gankro Adjust the clip region for shadow elements. This patch is intend to fix #1928. In webrender, shadow elements inherit the same clip with the original elements which leads the shadow to apply the wrong clip region when doing fast-shadow. To fix this, when adding a shadow line primitive, I adjust PrimitiveInfo's local_clip_rect to fit the correct clip region and apply the clip outside of the shadow to the shadow line primitive. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/webrender/2278) <!-- Reviewable:end -->
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Copying from my comment elsewhere:
Basically, gecko likes doing some cute tricks where it draws parts of the text multiple times with different clips to create the illusion of a single glyph/line across multiple runs with possible style changes.
Mostly this works fine, and can be naively lowered with no problem. However this causes a problem for fast shadows, because they inherit the clip from the original element. Therefore fast shadows with an offset will be clipped incorrectly and render broken.
So as a level-1 problem, when we clone the display item to push it in as a fast shadow, we also need to clone its clip and apply the shadow offset. However this creates a level-2 problem: translating the clip isn't always correct to do -- you don't want to translate a clip used for, say, overflow:hidden.
Under the current architecture there's a simple heuristic we can apply: clips that are pushed inside a shadow should be cloned and translated when pushing fast-shadows. These clips are necessarily just "part of drawing that part of the text", and not "real" clips.
Slow shadows appear to be unaffected.