The detection for the "main scrolled slice" does not work for pages from the parent process
Categories
(Core :: Graphics: WebRender, enhancement)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox72 | --- | fixed |
People
(Reporter: mstange, Assigned: gw)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
Firefox sometimes still renders tab content in the parent process. One example for this is about:support. When using OS compositor surfaces, on about:support, WebRender creates only one slice for the entire window and repaints on every scroll.
|
Assignee | |
Comment 1•5 years ago
|
||
Ah, I had noticed this and wondered what the cause was.
|
|
Assignee | |
Comment 2•5 years ago
|
||
I looked at a scene capture of about:config. The difference is that there is no iframe display item for the content in this case.
I think it should be easy enough to handle this in the WR picture cache slicing code. But before I do that, I guess it's worth checking that this is what we want / expect from Gecko in this case (i.e. if it's trivial for Gecko to have an iframe display item for content from the parent process, then that would also fix this issue).
|
Reporter | |
Comment 3•5 years ago
|
||
Gecko only emits iframe items in order to embed display lists from other processes. (And for videos.) In the "parent-process tab" case, the tab contents are part of the same Gecko display list as the window chrome. So I don't think we can easily emit an iframe item here; we would need to create a separate pipeline for the tab content items, and submit a separate display list to WR, which sounds rather complicated to me.
One thing we could do is to annotate the appropriate StackingContext with a "contains primary scrolled contents" flag. Would that help?
We could also just wontfix this bug. In the grand scheme of things it's not that important.
|
|
Assignee | |
Comment 4•5 years ago
|
||
We should be able to handle this in WR.
I prototyped a fix for it which ended up only being a few lines of code. It worked, but exposed an existing bug in some other tests, which is somewhat more complicated to fix.
But we need to fix that bug anyway, and then this should become trivial.
|
|
Assignee | |
Comment 5•5 years ago
|
||
For content that comes from the parent process (e.g. about:support)
the shape of the display list is slightly different. In these cases
ensure that we setup picture caching slice markers on the root
stacking context.
Pushed by gwatson@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/23882236aac3 Support picture caching for parent process content. r=kvark
|
||
Comment 7•5 years ago
|
||
| bugherder | ||
Description
•