Servo Coordination Meeting 2025/08/18

[mrego]

• Date: Monday 18th August 2025 at 10:00 UTC
• Location: https://meet.jit.si/Servo-Coordination
• Doc: https://hackmd.io/@rego/servo-coordination/edit

Note: Please add comments to this issue with topics you want to discuss in the call.

[nicoburns]

Fontations / HarfRust Integration

PRs:

• Add harfrust shaping backend servo#38707

• Fontations glyph rasterization backend WIP webrender#4872

• General font architecture

• Strategy for landing new backends

• Canvas fonts and IPC

[Narfinger]

Multiple Rendering Context RFC: - servo/servo#38594
IPC Channel improvements:

• Added Benchmark that tests serialization and deserialization of an enum. ipc-channel#409
• Unify error handling to have IpcError and TryRecvError be the main errortypes. ipc-channel#407

[mrego]

Fontations / HarfRust Integration

Nico: New libraries at Google, some of them already use in Chrome (skrifa and harfrust written in Rust). We want to use these libraries in Servo in the future.
There's been a github issue for a while but not a lot of work has happened. skrifa is more mature, harfrust is less evolved, so its performance is worse than harfbuzz so far.

Simon: Looks ok to introduce these libraries. Though martin mentioned he prefer to merge the code when it's ready to be used.

Nico: Not sure why. I've split the PR in smaller patches. And the addition would be quite simpler and small.

Christian: I'm just curious of the performance of skrifa vs other stuff we have.

Nico: I believe skrifa is pretty close to freetype if not the same, it's good enough for Chrome to ship it, it might be even faster (not sure). About harfrust, that's a bit slower, a couple of people are working on harfrust and they have managed to make it from 4 times slower to 1.5 times slower than harfbuzz (it's getting there but not there yet). See https://docs.google.com/spreadsheets/d/1lyPPZHXIF8gE0Tpx7_IscwhwaZa4KOpdt7vnV0jQT9o/preview

Rego: I guess we need to talk to Martin to understand why he thinks that, maybe it's the complexity to maintain both, but maybe if it's a simple patch like Nico has mentioned it could be ok behind a flag.

Martin: My main concern, maintaining multiple building configurations is kind of a nightmare as we usually don't notice breakage and so on. I think we can focus in one feature and make it very very good, but cannot work in a lot of them. I think harfrust is a great idea for the future, but it's not ready, but my suggestion would be to adapt the code and maintain things while things are not ready, and then switch to it when it's ready.

Nico: Main downside is that other people cannot use it as easily. It's working quite nice, only the baselines are not passing.

Martin: I think it has some missing features like subsetting.

Nico: I'm not sure we're using any of the missing features except baselines, maybe we have to wait or wait for them to be ready. I think a web browser doesn't use font subsetting capabilities.

Nico: For the canvas backends is possible to build them all and then enable the one with a runtime flag. Maybe we should test more things on CI.

Martin: My hope regarding canvas is that soon we can just remove the raqote backend, and I guess at some point we might need to add a skia backend and probably we have to choose between CPU and skia for CPU rendering, and not having two. Probably we also need that for printing.

Nico: I guess in many of these cases it'd be a tradeoff, like easier to build in Rust, or using the standard C library. I think it'd be useful to support multiple backends, maybe setup Servo so embedders of Servo and use their own backend and we only maintain one.

Martin: There's also the question of how much flexibility we want to provide. I think as a general goal for Servo we want to make it usable for people.

Nico: For me to compete with others, it might be helpful if we can do some things those engines cannot do, maybe the flexibility is an area where we can compete (though some other engines have multiple backends for these things).

Rego: Would it make sense to use a remote branch? So people could test it somehow easier?

Nico: If it's a PR it's already a branch at the end.

Rego: Yeah, I meant if we have a kind of "official" branch with a name.

Nico: I think it's not that much different any of the options.

Multiple Rendering Context

Christian: This is about having multiple webviews, and having all of them rendering independently. Put a RFC asking for comments, the code is working (not sure about WebGL or WebGPU), some people want this functionality, so it might be nice to have it behind some flag or something. I bring it here to get feedback from people.

Christian: We should follow up on zulip or on the PRs with some discussion.

Martin: I've a question, you added support for multiple windows, but does it support multiple webviews into the same window?

Christian: From Servo arbitrarily any windows on any rendering context. The hookup from servoshell only allows one window and one webview right now. If this code gets merged it'd be without the servoshell implementation currently, as a bunch of things need to be done to make it usable for other people.

Martin: We need to be able to have multiple webviews on the same window but sharing the web rendering instance but having different context (webviews side by side and things like that). I think it requires some changes in WebRender, as Firefox doesn't do this. Then there's support for Servo instances on multiple windows, different webviews have different web rendering instances (so you cannot share fonts and that kind of things), that means each webview has its own memory stuff.

Christian: Per webview group, it has one web render instance. But it allows multiple webviews now. Having different web renderers or different webviews, there's some code that mentions it's not done yet.

Martin: The first thing is about using the document ID, and every webview will take care of the entire rendering context, that requires us to support the same web rendering instance and different rendering targets that share some things. One window and different rendering context seems like the first thing. I think it requires some work on WebRender. Then once we have that, we could work on multiple windows, having different web rendering instances, and requires having some sort concept of a window in the inners inside of Servo, so you can make WebGL or WebGPU working.

Christian: Ideally you could have a single web rendering context used by multiple stuff.

Martin: We might be able to work on that and help to push things forward also, but cannot commit to that just now.

IPC Channel

Christian: There are a couple of PRs in the work, if I understand IPC Channel is a crate that is used by a lot of other people in the Rust ecosystem, but the current error handling is a bit weird, it spits out an encoding error (even when other errors are more appropriate). Another topic is the coding scheme, not sure if the current one is actually maintained, looking into possible alternatives.

Nico: It looks like Bincode 1 is still more used than Bincode 2, but it might be due to popular libraries using still Bincode 1 (like IPC Channel).

Christian: Bincode 2 is currently slower than Bincode 1, it's a bit hard to judge the performance of these tools. Depending on the format, there can be parity between both (or even bincode 2 being faster in smaller devices).

Nico: We probably need people that maintain IPC Channel to weight in on this, probably sagudev and jdm.

Christian: I was trying to clean-up all the error handling code, I've got some comments that we cannot do breaking changes. So it's something we need to discuss.

Rego: They're not usually in these calls, so discuss on zulip or github issues/prs.

Dev Tools

Rakhi: We've been working on create the basement to add breakpoints, so it exposes where the client can add breakpoints. We're also working on introducing actions like resume/pause when you reach a breakpoint.

SVG work

Mukilan: Inline SVG support landing last week. Looking into some small changes to see if it's possible to set the width and height of the SVG from HTML/CSS as that happens in some WPT test cases. If someone has tested and found issues, please let us know.

Rego: Is it enabled by default?

Mukilan: Yeah it's enabled by default.

Compositing mechanism

Dmitrii: Is there any documentation available on the compositing mechanism? I think this has changed since last time I looked into the code. I want to work on the text-overflow: ellipsis implementation, it'd be nice to get some help with the compositing part of the code and the recent changes.

Dmitrii: text-overflow: ellipsis shouldn't affects layout following the spec. If we change the symbols that we use for text-overflow: ellipsis we shouldn't change the layout of the page. The only way to do is to crop the picture that was already layout and put the symbols on top of it; you also need to respect all baseline features. It needs a good of Servo compositing mechanism.

Martin: Not sure why you need to do any work in the compositor, as it seems this will happen on the display lists construction. Probably this needs to interact with layout to get the baseline or font that you have to use. Maybe not display some glyphs and add the glyph for the ellipsis. Not sure if it involves the compositor.

Dmitrii: Thinking on where to put the cache of the characters.

Martin: You have to map the ellipsis with the specif font during layout most likely, and put the glyphs there.

Dmitrii: I thought this would be complicated if we're thinking in partial layout mechanism. I'll review the code again and ask more questions.