Open paulrouget opened 6 years ago
/cc @glennw @metajack @tschneidereit
WebRender is used directly in components/canvas/ components/compositing/ and omponents/servo/.
I don't see anything that would make this too hard.
Especially for customized and specialized renderers, this would be nice. For example, I'm developing a GIS / geospatial application using Vulkan as the rendering backend, where I transform points of the GPU and render them directly to the screen, which is very fast. But webrender is currently OpenGL-only, which makes integration in the existing code impossible. This would allow me to draw my stuff to a texture and then draw the webrender UI on top of it. This way I don't have to sacrifice performance (going through a pipeline like canvas / svg -> webrender OpenGL -> screen would unnecessarily slow things down).
For games, this is incredibly useful. Building good UIs for games is pretty hard, because every solution is tightly integrated with the backend. So in gamedev, most people roll their own layout system, just because there's no backend-agnostic layout framework.
It might be more immediately useful for webrender to support vulkan than for webrender itself to be optional, since reimplementing all of webrender's functionality is undoubtedly no small task.
But webrender is currently OpenGL-only, which makes integration in the existing code impossible
Sharing textures between OpenGL and Vulkan is possible using extensions, but native support is of course preferable, especially since using Vulkan might enable higher performance in general.
As of now, booting servo requires OpenGL, which, internally, will be used by WebRender.
It would be great to make Servo renderer agnostic. Maybe the embedder wants to implements its own way of rendering the page.
Ideally, nothing under
/components/
would need WebRender and OpenGL, just use a shared API (webrender_api?) to communicate with the renderer.Instantiating WebRender would happen under
/ports/
.