Consider not using Gecko display lists for hit testing
Categories
(Core :: Web Painting, enhancement, P2)
Tracking
()
People
(Reporter: mikokm, Unassigned)
References
(Depends on 1 open bug)
Details
Gecko uses display lists to supply hit testing information to WebRender. Hit test visible areas are collected from every frame visited in the layout frame tree during display list building. As of bug 1534549, this information is stored in the background display items created for the frame, or in nsDisplayCompositorHitTestInfo items if the frame has no background. During WebRender display list building WebRenderCommandBuilder uses HitTestInfoManager to deduplicate these areas and push the resulting WebRender HitTestDisplayItems in WebRender display list.
The empty implementation of nsDisplayCompositorHitTestInfo::CreateWebRenderCommands() shows why using display items for this is a bit silly - they do not do anything. Hit test items are also handled differently on the WebRender side, where they are added to a different list than the other items. Perhaps the biggest problem with the current approach is that we create a lot of these display items on the Gecko side: on YouTube they account for over half of all the display items (bug 1710978).
If transforms and clips were stored outside of display list (bug 1715110), we could do the same for hit testing information, and just collect a list of (rect, flags, spatial_id, clip_id) tuples that we can directly send to WebRender.
One difficult thing here is getting the CSS z-index and content sorting to work correctly, but it is probably possible.
|
Reporter | |
Updated•2 years ago
|
|
||
Comment 1•2 years ago
|
||
Could we do the same as we do for display lists, and adds the hit test entries to a collection of lists (like nsDisplayListSet), and then concat those together when we finish a stacking context? We'd need to add z-index to the tuple for the sorting phase, but that's probably ok.
We split nsPaintedDisplayItem out from nsDisplayItem for this reason too, so that hit test items could be much more lightweight and not carry paint-specific data. It's possible that we could do more there too.
Description
•