- Date: Monday 25th March 2024 at 16:00 UTC
- Location: https://meet.jit.si/Servo-TSC
- Status update
- Servo and SpiderMonkey Report
- Servo and 2d canvas (Vello)
- Servo support for Speedometer
- Wiki cleanup
- Crowdfunding
- Outreach
- AOB
Attending:
- TSC members: atbrakhi, cybai, gterzian, Loirooriol, mrego, mrobinson
- Other: cathiechen, DJMcNab, jschwe, KnorpelSenf, matlu, nicoburns, oluwatobiss, PoignardAzur, ststimac, Taym95, wusyong, zrhoffman
rego: One important thing is that in CSS layout support. Initial table layout has been enabled by default. It still lacks a bunch of features, but enabling them has allowed us to start improving our WPT pass rate in many different folders. Many of them were testing were tables.
rego: https://wpt.servo.org/
rego: Some of you may have noticed: Servo is part of Outreachy again. We are currently in the contribution period. Lots of new people contributing to Servo. Very nice for the project. Welcome to all of them.
rego: Lots of improvements to clippy and rustdoc.
rego: We have been working on issues with Android -- work a bit slow, but recently we landed support for the x86_64 platform (new android emulators). Still some issues.
rego: WebRender has been upgraded to the latest version. We are now very close to what Firefox is shipping.
gterzian: This topic is about a report that I have a first draft of. I have a PR that is a second draft based on feedback from Zulip thread. We are discussing whether it's possible to make Servo more modular in it's use of SpiderMonkey. There was quite a bit of contribution making some progress on this topic and the report is meant to inform that work and give a long term vision.
gterzian: Thank you very much. We have some interesting information in the second draft. React Native has something very similar to what the end result could look like for Servo -- an interface that hides the JavaScript engine you would be using.
gterzian: The goal is to collect more feedback and work more on the second draft and eventually publish it on the wiki or the blog or some other place.
gterzian: Do we want to publish it in some way?
17:10 rego: We did something similar last year with the report about Servo's layout engine. This was also published in the wiki, so it makes sense to do the same. Blog post, etc, etc.
Taym: I am planning to continue working on the remaining issues to remove the unsafe layer in the upcoming weeks.
gterzian: First step isn't to remove SpiderMonkey, but to user raw API less.
gterzian: gives a quick intro
gterzian: An issue and some consensus that we should replace the current backend to implement 2d rendering context on canvas element. Vello discussed as potential candidate. Discussion continues on Zulip. Discussed some proposed design. Since it was a long discussion, I decided to write it up in order to focus the discussion. Item is about whether or not we have consensus with Vello as replacement for raqote.
gterzian: There's a link to a short report and discussion. Vello is more actively maintained than raqote -- structure of Vello would allow to implement it without a backend. Vello works likes a library like JS or WASM and could run inside script. Uses WebGPU APIs that we offer to JavaScript. We could remove a lot of what we currently have -- canvas paint thread. What would remain is stuff not related to 2d context, but webgl context that still requires that mechanism.
martin: It feels like from my perspective a good bar for integrating with Vello is that it passes more canvas tests than Servo passes now
martin: in the history of servo there was cairo, and then skia; but then it moved to raquote; but it lacks a lot of features
martin: vello lacks some features that might be important to have support for canvas on the web
daniel: Just about strokes and text -- strokes as of last week are fully supported. There are some features (offset strokes?) where the code in theory in supports it, but the wiring isn't done yet. Joins and caps are supported.
daniel: As far as text goes, our API is not as connected...doesn't handle layout. You just give it glyphs to render.
daniel: There's no glyph cache, but adding that should be fairly transparent.
martin: that's good to hear, it looks like Vello has a more active community
martin: even at the time we can finish the integration, it could be in a better situation; and in a path to be able to pass all canvas tests
mrobinson: What do we lose and gain about removing the canvas thread.
gterzian: I can answer question about what we lose and gain by removing the thread.
gterzian: What I understood about Vello is that it uses wgpu and we use wgpu-core. wgpu is the fontend API...the DOM webgpu API. Vello registers some of its own shader and builds a list of commands using gpu command and queue and submits them similar to a JS library using the WebGPU DOM APIs. In terms of asynchonricity ...the work still happens on the GPU.
gterzian: We already have our own backend for...webgpu.
gterzian: My conclusion is that we would not be losing anything and we would be gaining something in terms of reducing complexity, because we'd be consolidating some of the logic inside the script thread itself and relying on existing WebGPU infrastructure.
martin: it seems our webgpu implementation is pretty basic and missing some stuff so far, we'd be using our webgpu implementation or we'll be using our glue into wgpu core?
gterzian: These are basically the same thing. It is patchy in spots. But this is a moment to be aware of these issues and address them.
nico: Vello stresses wgpu quite hard...only started working on Firefox recently. Unless the plan is to make the WebGPU entirely complete -- probably doesn't make sense to run on top of WebGPU. Not sure why it makes sense to do this...Servo is using wgpu-core as input to Vello, what is it translating that into?
gterzian: We can ask Nico's question to Sagudev
daniel: In terms of WebGPU compatibility -- all of development for native -- non web-platforms is through wgpu, just a thin layer on top of wgpu-core. If your wgpu-core bindings are complete then it should be following the same code paths. One thing mentioned was getting Vello's web demo working -- if APIs are there then it would be a good demonstration.
daniel: Previously blocked by ResizeObserver.
gterzian: ResizeObserver completely unrelated -- we're working on it. We could either have a demo that isn't using an API like that or we could finish the work we are doing on RO. I'm not an expert on the actual rendering, how wgu-core is integrated with how we show something on the screen, but there are security restrictions in multi-process mode. Some of the system resources need to be hidden from untrusted JS. That's probably why we have a backend running wgpu-core -- main process of Servo and DOM implementation that matches wgpu API running in untrusted script process.
gterzian: As sagudev has suggested in Zulip we could have a first prototype that bypasses that -- doing everything directly in script. This architecture that is mostly related to security architecture of web.
nico: My understanding is that Vello's API is essentially "draw shape" "draw glyph" could be serialized on script thread and passed to other context.
nico: As long as there isn't a bug in Vello. That shouldn't allow untrusted access.
gterzian: That's kind of the idea.
gterzian: Vello uses wgpu running in same process, but we separate that in Servo.
gterzian: Plan is actually to do it as Nico just sketched. There's two way we could do that. Vello just uses wgpu API that builds an abstract list of commands and submit it -- this could be done in two places. We could do this in the canvas paint thread and build and submit list of GPU commands. Totally possible.
gterzian: We could simplify the architecture. Vello is at the same level as a JavaScript library that could use a WebGPU API that can build up abstract list of commands and remove the canvas the paint architecture with additional threads. Opportunity to simplify things. I'm not sure what would happen if we submit commands to from two different instances. We are running wgpu core in webgpu backend -- components/webgpu. If we start running Vello using another instance
martin: I understand there are different graphics contexts, I'm skeptical about implementing on top of webgpu API; if we could have our own API that might be better; I'm afraid we do one step and the next one never happens
gterzian: We could submit in two places canvas thread and webgpu or both in one place -- both are risky. I like second approach. WebGPU makes sense. Perfect opportunity address these issues.
rego: Closing this topic as it's taking a lot of time, discussion should carry on in Zulip to try to find some agreement on the plan here. Experimentation can happen meanwhile.
rego: Raised by mats. Support for Speedometer and other benchmarks. No work on Servo performance recently. If people are interested in working on this, there's already an issue about these (linked above). They could start to identify missing pieces.
rego: servo/servo#16719
gterzian: I tried running the test suite. You can run parts of the test suite like browsing web app. There's some simpler part of the test suite that we can support. I tried running by hand one part that is like a todo app like jquery. One thing we can do is to run parts of the test suite and run them in some automated fashion. Running the suite as a whole doesn't seem to work.
nico: Servo doesn't support contenteditable.
gterzian: Right.
rego: People can identify missing features and work on them.
nico: Seems like a bit part was just running todo mvc under different frameworks
nico: Other parts were testing more complex features.
nico: subset seems sensible to me
gterzian: Agree.
rego: Discussed a while ago on Zulip. The Servo wiki has a lot of pages that are outdated. A few ideas: moving them to an archive branch and cleaning up the main branch -- on the wiki you only see the active thing. If you need to query for old things, you query the archive branch. There was a proposal from Delan about maybe using mdbook (common in other rust projects). Lots of positive reactions. We can start moving things there and simplifying things.
rego: That could be the next steps forward.
martin: I like the idea to switch everything to mdbook, it makes things easier to have doc updated; we could put things on its own doc even; and end up turning off the wiki
martin: it could open opportunities to integrate the API doc with our existing documentation
nico: I don't think the markdown files on the repo are not a great way to help people find information, the book seems better
nico: current doc isn't good for end users. Not obvious. mdbook probably easier to use. We could merge things.
rego: Regarding the plan to move to OpenCollective for Servo. We have announced it this month. We have also enabled GitHub sponsors, which sends money on a monthly basis to OC. Apart from that there was the LF Crowdfuncing platform (rego links to it). We are planning to close this. They have paid the AWS costs from H2 of last year -- previously paid by Igalia.
rego: https://servo.org/blog/2024/03/12/sponsoring-servo/
rego: LFX: https://crowdfunding.lfx.linuxfoundation.org/projects/servo
rego: This was around $700. Apart from that they are planning to move the remaining money to OC (~$2000). At some point when it's in OC we will decide how to use this money.
rego: We will keep you posted when the LF transfers the rest of the money.
rego: OS North America we have a talk on Servo which Rakhi will give.
rego: https://ossna2024.sched.com/event/1aBNF/a-year-of-servo-reboot-where-are-we-now-rakhi-sharma-igalia
rego: We have the RustNL that some folks here are planning to attend, but I don't know exactly who -- but there will be people from the Servo project so some discussion will happen there.
rego: https://2024.rustnl.org/
After that the next event is the Web Engines Hackfest that takes place in A Coruña which will have a bunch of people from the Servo team. People are open to join.
rego: https://webengineshackfest.org/
rego: No time for ABO this time. Thanks everyone for joining the call.