We want to replace raqote (unmaintained, software based) with vello (state of art; wgpu based) for 2d canvas rendering. Relevant chat on zulip: https://servo.zulipchat.com/#narrow/channel/263398-general/topic/Using.20Vello.20in.20Servo

History

Initially Servo's 2d canvas impl used azure/skia,
because migration to pathfinder seems hard, servo migrated to raqote as temporary measure to remove C dependency.
Now both pathfinder and raqote are barely maintained. Because of this there is abstraction provided in canvas (webgl thread), but we cannot use those for vello, which will mostly run in content process.

Workpoints

• allow wgpu to take custom abstraction: Support extern context impl gfx-rs/wgpu#6658
• create abstraction for canvas in content process. There is CanvasState struct that serves similar role, but it's currently leaky with IpcChannel:

  servo/components/script/dom/canvasrenderingcontext2d.rs

  Line 108 in 37695c8

  pub(crate) fn get_ipc_renderer(&self) -> IpcSender<CanvasMsg> {

• add feature/pref for 2d canvas
• add vello as new abstraction provider (behind pref/feature) all running in content process (single thread image getting)
• integrate vello with servo's webgpu stack, by writing own wgpu abstraction and deal with presentation

Alternatives considered

• run vello in separate thread (we want to avoid another thread)
• reimpl vello renderer using WebGPU dom objects (making wgpu abstraction on top of our webgpu impl is easier and more flexible if we ever want to use more wgpu based libraries)