Describe the new feature:

We have several issues(#33310,#36821) and zulip topics about improving our rendering stacks. While many are trying different approaches in different components, I feel like we have a concensus that we all want Servo to be better and more modular. Servo currently is still tightly coupled to Webrender and OpenGL. As OpenGL has been replaced by Vulkan and many GUI projects have moved to other libraries like Wgpu, it would be best if we could get a renderer that we have better control. Or even better if we can abstract it into traits, so we can implement with exsiting rendering libraries like Vello to avoid complex GPU issues.

Here are the list of revelant calls of webrender from compositor that we need if we want to add others implementions/traits:

Renderer

• update & render: With the design of webrender, we don't often call its renderer directly. We basically just need a method to ask for renderering

RenderApi

Webrender provides a channel with several methods for convenience. Most are just utilities with send_transaction as the main gateway.

• report_memory
• save_capture
• generate_font_instance_key
• generate_font_key
• generate_image_key
• flush_scene_builder
• hit_test
• send_transaction

Transaction

A Transaction is a group of commands for webrender to apply to a document. Whenever compositor receives messages or updates from embedders, it will try to compose following commands:

Image Management

When the compositro receive CompositorMsg::AddImage and CompositorMsg::UpdateImages

• add_image
• update_image
• delete_image

Font Management

• add_raw_font: when compositor receives CompositorMsg::AddFont
• add_native_font: when compositor receives CompositorMsg::AddSystemFont
• add_font_instance: when compositor receives CompositorMsg::AddFontInstance
• delete_font & delete_font_instance: when compositor receives CompositorMsg::RemoveFonts

Display List & Frame

The last and the most improtant ones are set_display_list and generate_frame. The display list is used by layout component and it will send to webrender eventually for webrender to build and generate the frame. Based on RenderReasons, there are three kind of conditions:

TESTING

• Only when toggle_webrender_debug is called

SCENE

The actuall scene to build and apply to the document. It's called when compositor receives following messages:

• CompositorMsg::SendInitialTransaction
• CompositorMsg::SendDisplayList

...and when it needs to manage webview and calls send_root_pipeline_display_list eventually. Here are the calls that are related to this method:

• CompositorMsg::CreateOrUpdateWebView
• CompositorMsg::RemoveWebView
• show_webview
• hide_webview
• raise_webview_to_top
• move_resize_webview
• set_hidpi_scale_factor
• resize_rendering_context
• on_zoom_reset_window_event
• on_zoom_window_event

APZ (Asynchronous Panning and Zooming)

This is called when we need to zoom or scroll. Here are the related messages and methods that call it:

• CompositorMsg::SendScrollNode
• resize_rendering_context
• perform_updates

Alternative Backend in Webrender

This is another approach I think could be possible, if we couldn't use other rendering libraries to implement the items above(especially display list). There are only two modules have directly OpenGL usages which are Renderer and Device. While they are massive modules, they have clear GL calls from method calls and channel messages. We could use other graphic libraries like Wgpu to implement the relative calls or translate to similar concepts.

Based on the feedback from the comment, I looked into the possibilty for wgpu support in webrender deeper. I think we have the chance to ahieve it indeed. The GL calls are mostly located in Device struct and many method calls could be no-op. There are some trivial gl types outside of it, but we should manage to move them back into the same module.For GLSL shaders, we could add another build script to tranlate them into SPIRV. So the general plan to add the support of wgpu is following:

• Add build scrit to translate GLSL to SPIRV
• Abstract device module into trait or feature flag
• Add wgpu port of Device struct implementation. Here's the list of method.
• SPIRV shaders might need some tweak to work well under other stacks like Vulkan

Renderer Device

The device module is a huge component in renderer, but it mostly handles GL commands and buffer management. Here's the list of method and I'll list some important one here. I think it should be less scary if everyone understand what they are:

Frame

• begin_frame
• end_frame

VAO

• bind_vao
• create_vao
• delete_vao
• update_vao_indices
• update_vao_instances
• update_vao_main_vertices

VBO

• allocate_vbo
• create_vbo
• delete_vbo
• fill_vbo

PBO

• create_pbo
• delete_pbo
• map_pbo_for_readback
• read_pixels_into_pbo
• read_pixels

Texture

• attach_read_texture
• bind_texture
• copy_entire_texture
• copy_texture_sub_region
• create_texture
• delete_texture
• upload_texture

Shader

• bind_shader_samplers
• compile_shader
• set_shader_texture_size
• create_program
• create_program_linked
• bind_program
• delete_program
• link_program

FBO

• create_fbo
• delete_fbo

Render Target

• bind_draw_target
• bind_read_target
• blit_render_target
• clear_target
• invalidate_render_target
• reset_draw_target
• reset_read_target
• reuse_render_target

Depth Target

• depth_targets_memory
• invalidate_depth_target

Another interesting approach suggested by @sagudev is we can use ANGLE's WebGPU backend. However, part of the reasons for this feature request is to extend the modularity and expand the support to wgpu ecosystem. I'm not sure ANGLE could provide some extensions that we can still get WebGPU types to embed with other projects.

Let me know what do you think and we can discuss and open more granular issues. There are also some tasks we can do already like adding feature flag to move components rely on OpenGL heavily behind it, and checking Servo can be built and run without any(or dummy) rendering context.