1284053 - Make moz-element painting contribute to the main display list

Status: NEW

(Core :: Web Painting, defect)

Description

[Matt Woodrow (:mattwoodrow)]

Currently -moz-element paints by using a separate call to PaintFrame() for the painted element within background drawing. 

This breaks DLBI as the display items for the -moz-element content aren't within the display list for the page, so instead we have to use SVG rendering observers on the referenced content and just invalidate the entire background when anything changes. This is fairly complex and leads to bugs like 1282312.

It also means that we can't properly support async-video, async-animations etc within -moz-element content.

Ideally we'd be able to build the display items for the referenced content once, and then just attach them into the display list in multiple places, that way we can re-use the layer. I don't think we can guarantee that we'd actually build identical display items though (especially wrt dirty rects and clipping), so this probably won't work.

I think instead we could just duplicate the display items, and override GetPerFrameKey() for all items within the -moz-element content so that they are unique and differentiated from the original content. I guess if someone references the same content in a huge amount of places then we could end up overflowing the key variable, but that seems like a rare corner case.

This doesn't get us the advantage of sharing layers, but it does fix most of the original stated problems. Invalidation would work correctly since DLBI would have access to all the display items to know what changed and we could get rid of the rendering observers. Display items for video would pick up the same ImageContainer for all instances, so async video updates would modify all places the video is shown. Content with async animations would have the animations added to each of the layers separately, so they should all be animated by the compositor.

I think it would even work for the case when we have an async scrollable element within the referenced content. Both the 'real' content and the -moz-element version would get the FrameMetrics for the scrollable, and when you scroll the real one, APZ should update the scroll position on the referenced one. We'd need the -moz-element ContainerLayer to be treated as leaf for APZ hit testing though, since we don't want to allow scrolling to originate on the referenced content.

Comment 1

[Kartikaya Gupta (email:[e-mail])]

We could probably get the desired APZ interaction by fiddling with the event regions appropriately. Based on what you said I think pretending like the -moz-element frame has touch-action:none (i.e. adding it to the mNoActionRegion) should do the job.