- Date: Monday 23rd September 2024 at 15:00 UTC
- Location: https://meet.jit.si/Servo-TSC
- Issue: #101
- Status update
- SVG images support
- License approval of two small non-MPL2 crates
- Using TLA+ to model concurrent algorithms
- CI runners status
- Crowdfunding
- Website revamp
- Ideas: made width page, partnership page
- Outreach
- AOB
Attending:
- TSC members: gterzian, mrego, mrobinson, nicoburns
- Other: jschwe, Shark
rego: Lots of updates. CSS flexbox enabled by default -- improving pages, RTL support landed, there have been improvements in servoshell, more progress on WebXR, gamepad API enabled by default, Android binaries are now shipping on servo.org, OpenHarmony support has just landed in servoshell. Lots of stuff this month.
rego: That's just this month, preparing the blog post with everything.
rego: servo/servo#33310
rego: Lots of discussion issue above. The thing is that Servo doesn't have SVG support right now. If you have an SVG image, it doesn't get rendered. Even worse if you try to create and manipulate SVG elements, the script might fail and the page might be blank. The goal is to add basic support for SVG, full support a lot of work.
rego: Should we consider a third-party library or just add support for the rendering part of SVG. It might not be too much work if it can be done in weeks or months.
nico: I was initially very pro-resvgbecause I've read articles by RazrFalcon. SVG sounds complicated. I have looked into the actual code a bit more then. I do agree that some of the stuff it does, Servo already does like text layout. Some other things like elements would need to be implemented from scratch. I think that long-term it's probably not a good solution. Short-term since we already have support for rendering raster images and we have support for that, it would be possible to plug it in as a black box and would get us short term static SVG support. I don't necessarily have strong opinions on what...
nico: There's a related issue: Servo has no Vector path rasterizing library. If we do want to start building our own SVG support, that seems like a key decision.
martin: I don't disagree much with nico
martin: one thing of if we use something like aria-svg, the question is how long it could take to add svg basic support
martin: what I have hear from Igalia experts on SVG, they mentioned a weekend project is enough to render SVG without all the DOM complex stuff; maybe with a few more weeks we could have something in the right direction
martin: if other svg libraries, if it's something easy to integrate, it could be an option for the short-term
martin: about the rasterizer, I agree it's needed for a bunch of things, including SVG
martin: I'd love to use Vello, but it seems it's not there quite yet
martin: my opinion right now until vello is ready, would be to use skia in rust and use the pre-built binaries, that's probably the easiest thing to do, because skia has all we need and it's a complete rasterizer; with the idea that one day we could use vello
nico: I don't strongly oppose skia. It's interesting that you consider it the obvious. To me the obvious choice would be tinyskia. It's much smaller from a binary and it doesn't have a bunch of build problems that come with skia. I guess I'm just like...Chrome just uses skia...there's no WebRender. I know we are as well with tiny skia, but it's much smaller.
martin: why skia? skia is used by all the other web browser engines, if you not count core-graphics on Mac for WebKit; I don't know if tiny-skia supports text, it seems from their github it doesn't, it's a big thing for SVG
martin: chromium uses skia, but also hast a giant compositor; accelerated textures on the page happen on the compositor; servo used to have that code, but doesn't need it now thanks to webrendern, includes things like css 3d transforms or many other things
nice: Regarding tinyskia and glyph rasterization, but you can do it with skrifa and swash if you want to. swash is an open-source crate, but skrifa is the one that Chrome is now using to replace freetype.
nico: skrifa: In the example we've done the integration in the parley repo but it doesn't depend on parley. The other option for glyph rendering is to use the WebRender rasterizer.
nico: Skrifa + tiny-skia glyph rendering example https://github.com/linebender/parley/blob/main/examples/tiny_skia_render/src/main.rs
martin: skifra does in a way of glyph renderer, it provides some paths, that right now in chrome they can be rendered by skia, so it's similar; also you need to keep a glyph cache; webrender already has a cache, and I assume skia also has one, it'd be nice not to write a new one
nico: would it be possible for webrender to expose the glyph cache
martin: there would be needed some rewrites
martin: my idea is that we don't have to do all these things, and we use the thing that is already done; or then we switch to vello or tiny-skia when it's ready
martin: it's different than SVG, because when we write the SVG code is to stay there forever
nico: I'm concern about build requirements for skia
nico: I'd not strongly oppose
martin: I guess we would need to check if it's a problem in some platforms
rego: Do have any plan for SVG? Do we want to do the weekend experiment?
martin: probably giving 1-2 weeks to try the SVG support makes sense, for the SVGElement error, we might want to workaround it meanwhile
nico: would it be possible to have the SVG code on its own crate?
nico: The other thing I was wondering if we build our own SVG support. Would it be in its own crate? Will it be decoupled?
martin: initially could be more decoupled but it'd get more and more into the layout code
nico: I guess it can be possible to de-couple layout as well. In blitz we have text and box layout entirely decoupled. Maybe that could be the same for SVG?
rego: Trying to decouple things sounds like a good long term goal.
rego: #101 (comment)
rego: There was a comment on the agenda issue about integrating these two small crates with different licenses. Does anyone have a problem with that.
nico: I had looked and it seems that this isn't request to relicense, but to move code from outside to inside. We've got lots of other crates that have a similar license.
rego: I also think it's fine.
jonathan: Someone should double-check that it is actually carrying the accurate license. I guess if it goes under the Servo organization, someone should double-check to make sure.
martin: I find a bit odd the request, as the code in servo there are many with different licenses
martin: I don't think we have any rules about the license of the code in the organziation, other than being open source
martin: it seems pretty straight forward, I don't know the problem
martin: even if it's not in Servo organization, it's going to be part of Servo anyway
jonathan: Do we have an official policy? As a user of is the applied license MPL, since that's the stronger license.
martin: I don't think there's an official policy, maybe when Servo was part of Mozilla, probably code from Mozilla had to be MPL
martin: I don't think we've ever discussed a license policy
rego: I don't think so, but we could have that discussion at another time.
rego: We had other dependencies with similar licenses?
nico: Do we know who the maintainers of rusturl are? On one hand, don't see problems with other repos, but on the other hand why doesn't it just go into the rust-url repository like other crates?
rego: I think valenting is from Mozilla.
nico: It looks like an abstraction over different unicode handling libraries.
rego: rust-url itself has this Apache license, so it's unclear. Not sure why it's an issue.
nico: (Looks like it relates to servo/rust-url#939)
rego: We can take an AP to draft a license policy.
rego: https://medium.com/@polyglot_factotum/re-fixing-servos-event-loop-e00bdf267385
gregory: I've been using it on my side. I think everyone has heard of it, but I don't think everyone has used it. It's a tool to model concurrent algorithms. I've used it to mode some of the algorithms we use that are hiding in our event loop...to fix issues related to the HTML event loop. I wrote a blog post about this. It's useful for anyone if you use it on your own. It's better than English. If anyone is interested please reach out. I could tell you more about it or if you have an idea about using it, I could discuss it with you and tell you if it's a good idea or not. Please reach out if you have questions.
rego: Delan and others have been helping to set these up. We have self-hosted runners set up for Windows and Linux builds (under 10 minutes both).
rego: So far we are spending 125 euros per month. The next plan would be adding macOS build jobs to reduce the time further.
rego: https://opencollective.com/servo
rego: The OpenCollective has got 17k dollars. We are using that money to pay the self-hosted runners. The Linux Foundation crowd funding page. We discussed last week to close it definitively. Most of the money was already transferred from there. The point here is for ideas for how to spend the money. We will likely spending ~2k a year on runners, but that's still not all of the money. We still have more. We should think of ideas for how to use the money.
rego: We don't need to decide anything today. We can finish on the Zulip channel.
martin: I like the idea of using some of that money to fund an Outreachy internship
rego: Servo has been participating in Outreachy. We had one intern during the first cohort of the year. Eri brought back devtools support. It was a great result for the project. If people think that's an interesting way to spend money. It's been running for many years and many projects. For me it also sounds like a good idea.
rego: We can think about this and collect more ideas.
rego: In December Servo is participating again in Outreachy and maybe we want to get an extra intern for this money.
nico: It may be that we want to spend a bit more on build servers. We've done Windows/Linux, but not macOS.
rego: That's part of the plan definitely.
martin: I don't know if the build infra in self-hosted runners are running WPT tests yet, it'd be something nice to have
nico: Improving build would help to make the project more accessible. There are many platform specific failures and it's hard to check those when running locally.
martin: we will need to start adding specific results for platforms, or improve our runner so it depends less on the environment
rego: Servo.org website was there when Igalia started to work on the project. We cleaned up a bit, but it was mostly there. There are a bunch of ideas to add more pages. nico had a WIP PR to add a "made with" page now that we have more experiments with Servo.
rego: Another idea to add a partnership page to highlight companies working on the project.
rego: Some discussions probably the web site could be a bit better at selling Servo. People taking a quick look could see what Servo is.
rego: There are a bunch of things we can work on. Igalia has plans to work on this in Q4.
rego: The point here is informative. Any feedback we can collect. Everything will be done in a repository. We have a rough draft of teh new page.
martin: in addition to the page with companies we partner with; it'd be really nice to have a page highlighting all the individuals who donated money
nico: It might be nice to have some page highlighting crates that the Servo organization hosts. I think it would be good to make it a bit more obvious the links to Zulip and TSC. The Zulip link is in the footer for example. The Servo Zulip doesn't get that much traffic compared to smaller projects. Maybe we could do a better job of advertising it.
rego: Yeah, thanks for the suggestions. Both seem like a good idea.
rego: Maybe highlighting a few crates...
rego:
rego: https://servo.org/slides/2024-09-19-lf-europe-member-summit/
rego: Last week I was in Vienna for the OS summit and the LFE summit. For October, I think we have a few events. I think that Gregory will be at GOSIM in China and Rakhi will be at the Ubuntu summit in Germany talking about Servo.
nico: We discussed doing a release of selectors, partly because someone requested it and partly because it's part of releasing stylo. I submitted a patch upstream, but maybe someone else should take a look. I think there are a few other crates that are dependencies that also need to be published. Just wanted to raise that, because I don't have publish permissions.
rego: I think Martin can help to relase them
martin: yes, sure