Decorated Web View about servo HOT 4 OPEN

That looks like something that should be solely the responsibility of the embedder unless I misunderstand the intent here. Imaging each and every embedder coming with their feature request: that doesn't scale and looks like a layering violation.

from servo.

In my original Zulip thread, I did try to start by writing my own painter implementation. But it fell into the pitfall similar to egui that I need to maintain multiple openGL context versions across different platforms. While Webrender is already handling this. And there will be webview treated as context menu later. It will be impossible to clip it right without accessing the Compositor.

Besides, the way of handling webview already includes updating webrender in Compositor, and this is all before the layout crate. I think it's okay to extend such a feature.

from servo.

In my original Zulip thread, I did try to start by writing my own painter implementation. But it fell into the pitfall similar to egui that I need to maintain multiple openGL context versions across different platforms. While Webrender is already handling this. And there will be webview treated as context menu later. It will be impossible to clip it right without accessing the Compositor.

It feels like we are going about things the opposite way. It seems like the embedder should expose an OpenGL context or surface to Servo, rather than the embedder getting it from Servo. In this model, there can be multiple top-level WebView data structures that render to the surfaces or contexts applied to them and then the embedder is responsible for managing where they are placed and what chrome surrounds them. In this case, if the WebView contents are rendered to a texture, the embedder becomes responsible for making sure that the text is rendered to a polygon with rounded edges. I don't think Servo should be handling this at all.

In this case it might make things more expedient, but I don't think it will lead to a high-quality embedding API.

from servo.

It feels like we are going about things the opposite way. It seems like the embedder should expose an OpenGL context or surface to Servo, rather than the embedder getting it from Servo. In this model, there can be multiple top-level WebView data structures that render to the surfaces or contexts applied to them and then the embedder is responsible for managing where they are placed and what chrome surrounds them. In this case, if the WebView contents are rendered to a texture, the embedder becomes responsible for making sure that the text is rendered to a polygon with rounded edges. I don't think Servo should be handling this at all.

The current restriction is that despite the embedder having a webrender context, it doesn't really control the behavior of web views. Instead, it listens to servo messages about the web view's behavior. The embedder can get the FBO, but it already contains all webview composites. It can't determine the exact timing of each web view compositing and rendering either.

Perhaps it's also time to consider redesigning the composite and present APIs, making them more ergonomic and allowing the embedder to control more of the behavior of the web views.

from servo.