Closed Bug 1480566 Opened 2 years ago Closed 1 year ago
Fission: Someday support filters on cross-origin OOP iframes
Currently filters will always fallback to inactive layers and render locally in it's content process. When OOP iframes are enabled, this will result in a blank space where an OOP iframe should be. WebRender, which works in the compositor with a view of all content, supports rendering a subset of filters natively, but not all. For the filters we support, everything should continue working. For the filters it doesn't support, we fallback to blob rendering. Blob rendering works by taking a recording of content we don't natively support in WebRender. Currently there is no way to express content unknown to the recording, such as an OOP iframe. So with these filters we will also have a blank space where an OOP iframe should be. We have a couple of options here. 1. Don't support filters on OOP iframes. Or possibly iframes of different origin. This seems to be the behavior Safari has. We could add a telemetry probe to see how common this behavior is relied on, to know if it's worth the effort. This might also be viable as a V1 for OOP iframes. 2. Add slow support in the compositor/webrender for filters on OOP iframes 1. For current Gecko, we could support filters in the compositor fairly easily if we were to reuse our software FilterNode implementation and take a readback hit 2. For WebRender, we could extend our blob images to support referencing unknown content and resolve the iframes in the compositor. This could be a tricky as it would make blob images depend on output from WebRender. Both of these options would not be optimal, but they would be on the lower end of implementation difficulty. 3. Add native support in the compositor/webrender for filters on OOP iframes 1. For our D3D11 compositor, we could use our D2DFilterNode with some DirectX interop. 2. For our OpenGL compositor, we would need to write shaders or maybe use SkiaGL 3. For our basic compositor, we could use our SoftwareFilterNode with readback. 4. For WebRender, we would need to write new shaders for the missing filters. Each of these would be much faster than the naive approach, but would require more work. Especially as it requires specific support for each backend.
Fission Milestone: --- → ?
Summary: Determine if/how we need to support filters on OOP iframes → Someday support filters on cross-origin OOP iframes
Summary: Someday support filters on cross-origin OOP iframes → Fission: Someday support filters on cross-origin OOP iframes
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.