How does that sound?

Thanks for looking into this.

For my understanding, it is correct that you are now relying on Vello's internal use of wgpu? How does that interact, if at all, with our own use of wgpu-core in components/webgpu?

My initial proposal in zullip was to rather explore a different architecture, one that would still be using our own components/webgpu infrastructure.

As I remember the Vello codebase from a year ago, there was an interface for some sort of rendering backend, which then would use wgpu, but in theory we could implement our own(perhaps using our WebGPU dom objects), and then run vello directly in script and send commands to components/webgpu. The main benefits, in theory, were re-using same infra as our WebGPU implementation, and also the ability to remove the canvas thread. Perhaps it could also remove the " uses normal wgpu, so we block on GPU work" part.

Anyway, if you are making progress with this I think it's a good idea simply to remove the raquote dependency, although longer term perhaps it could be replaced by something close to my proposal?

Anyway, if you are making progress with this I think it's a good idea simply to remove the raquote dependency, although longer term perhaps it could be replaced by something close to my proposal?

That is eventual plan, but vello is missing some stuff.

My initial proposal in zullip was to rather explore a different architecture, one that would still be using our own components/webgpu infrastructure.
As I remember the Vello codebase from a year ago, there was an interface for some sort of rendering backend, which then would use wgpu, but in theory we could implement our own(perhaps using our WebGPU dom objects), and then run vello directly in script and send commands to components/webgpu. The main benefits, in theory, were re-using same infra as our WebGPU implementation, and also the ability to remove the canvas thread. Perhaps it could also remove the " uses normal wgpu, so we block on GPU work" part.

We actually just need to write custom wgpu backend that uses our webgpu objects (sends IPC messages to webgpu thread). Anyway, vello started going into different direction, exploring more hybrid (because current vello GPU requirements are high in terms of features due to compute shaders) and cpu only approaches (the last one is only as fallback). Given this new circumstances I think this makes more sense (although I would be interested in exploring for vello to still live in content process). But I have an idea how we can still use our webgpu thread but keeping vello out of content process (canvas_paint_thread would send IPC to webgpu). Why? To better support hybrid.

For my understanding, it is correct that you are now relying on Vello's internal use of wgpu?

Yes.

How does that interact, if at all, with our own use of wgpu-core in components/webgpu?

I have yet to check it, but I think it's all good (we run from different wgpu Instances) although we are currently using different wgpu versions which could mask the problem. But we need to force vulkan (llvmpipe) in CI or else it will use GLES which fights with servo's uses of GL (we might have same problem with GLES in webgpu).

That is eventual plan, but vello is missing some stuff

What is missing?

although we are currently using different wgpu versions which could mask the problem

A Vello release with WGPU is planned within the next couple of weeks :) (and I'm pretty sure it will work just fine with the same version of WGPU).

That is eventual plan, but vello is missing some stuff

What is missing?

Filter, but this is known in vello: linebender/vello#476

although we are currently using different wgpu versions which could mask the problem

A Vello release with WGPU is planned within the next couple of weeks :) (and I'm pretty sure it will work just fine with the same version of WGPU).

Yeah, the only potencial problems can be statics in wgpu or some other global states that are shared between wgpu instances (or servo in case of GL). But that's probably just me being paranoid (although keep in mind that typical wgpu users do not have multiple instances across multiple threads).

Sorry that I haven't gotten a chance to look at this yet. I hope to do so in the next couple days. This is very exciting! I would be in favor of removing the raqote backend even if some thing in Vello are missing. I think putting all of our effort behind a single canvas is a useful side-effect of removing support for raqote.

I would be in favor of removing the raqote backend even if some thing in Vello are missing. I think putting all of our effort behind a single canvas is a useful side-effect of removing support for raqote.

Currently, I think we should keep both for now:

1. vello backend isn't complete yet, with the biggest problem being: canvas: Add vello backend #36821 (comment) (that I will prefer to defer to follow up as it will raise complexity significantly).
2. Performance is currently pretty bad. Reasons for this are twofolded:
   1. We are blocking on rendering
   2. raquote updates drawtarget as soon as new command is issued, thus effectively making it async (we do not block content process on completion most of the time), while for vello we just record commands and do actual drawing when requested.

Also here are current test results: https://github.com/sagudev/servo/actions/runs/14968535017

EDIT:
3. Vello requires WebGPU capable graphic which is higher requirement than current gles2 capable device.

🤖 Opened new upstream WPT pull request (web-platform-tests/wpt#52971) with upstreamable changes.

📝 Transplanted new upstreamable changes to existing upstream WPT pull request (web-platform-tests/wpt#52971).

So many rebases to solve merge conflicts, most of which are actually my fault.

Heh, another rebase.

I'm impressed! The new backend is really readable. You've done great work to improve all the canvas code for this change.

Yeah, that was the goal. Initial backend code was much larger and complicated. I was also able to upstream euclid <-> kurbo From/Into in kurbo, so that also helped.

Congrats on landing this!