Closed
Bug 1016982
Opened 11 years ago
Closed 9 years ago
Async pannable scroll layers ignore scrollbox corner radius
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
DUPLICATE
of bug 1148582
People
(Reporter: mstange, Assigned: mstange)
References
Details
Attachments
(2 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/html
|
Details |
The clip wasn't using the border radius.
Attachment #8430048 -
Flags: review?(tnikkel)
Comment 1•11 years ago
|
||
I think all our layers backends support mask layers for rounded rect clipping. But do we still want to ignore rounded rect clipping on b2g and/or android so we don't have a mask layer for perf reasons?
Assignee | ||
Comment 2•11 years ago
|
||
Are mask layers that expensive? I was of the impression that they were the fastest way to get the desired effect (i.e. scrolling inside rounded clips). And I think rounded scrollboxes are uncommon enough that the affected pages can live with a small perf hit, and that that hit would be preferable to having the radius ignored completely.
Comment 3•11 years ago
|
||
I'm not sure how expensive they are, but they are surely more expensive then not doing them at all. :) They'd also increase our memory use.
Assignee | ||
Comment 4•11 years ago
|
||
Fair enough. Who can make the decision here?
Comment 6•10 years ago
|
||
Mask layers are expensive but in some cases they're the only way to have proper rendering with active layers. Aside from the memory usage increase they will also increase the time to build a transaction (latency). When compositing the mask layers will account for more memory bandwidth usage and dependent texture reads.
The question is if the active layer that is causing us to require a mask layer is saving more time then the mask layer is costing. I guess in most cases the answer might be a net save if we have async pannable content there.
IMO we should support them unless we take a clear and explicit decision to cut corners (that pun was by accident I swear).
Nevertheless we should do some profiling with and without mask layers to get some true numbers.
Flags: needinfo?(bgirard)
Assignee | ||
Comment 7•10 years ago
|
||
Thank you.
(In reply to Benoit Girard (:BenWa) from comment #6)
> The question is if the active layer that is causing us to require a mask
> layer is saving more time then the mask layer is costing.
This patch does not change whether a scroll frame gets an active layer. At the moment, as soon as you start async panning a scroll frame with rounded corners, the corners become square, and this patch makes them respect the corner radius again (and triggers mask layer creation and so on).
> IMO we should support them unless we take a clear and explicit decision to
> cut corners (that pun was by accident I swear).
Heh, good. I agree. :)
> Nevertheless we should do some profiling with and without mask layers to get
> some true numbers.
Alright, I'll do some profiling tomorrow.
Assignee | ||
Comment 8•10 years ago
|
||
Assignee | ||
Comment 9•10 years ago
|
||
With the patch applied, having border-radius makes the difference of 20fps vs 60fps on my Hamachi... this is much more expensive than I thought it would be. And the fill rate numbers go through the roof.
Assignee | ||
Comment 10•10 years ago
|
||
(In reply to Markus Stange [:mstange] from comment #9)
> And the fill rate numbers go through the roof.
And that's because a mask layer on a container layer forces the container layer to use an intermediate surface, and the intermediate surface is sized to the whole display port. This needs to be fixed. I'm on it.
Assignee | ||
Comment 11•10 years ago
|
||
Comment on attachment 8430048 [details] [diff] [review]
v1
I've filed bug 1016982 about the performance problem. Let's not land this patch until it's fixed.
Attachment #8430048 -
Flags: review?(tnikkel)
Assignee | ||
Comment 12•9 years ago
|
||
This was fixed by one of the patches in bug 1148582.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•