-
Notifications
You must be signed in to change notification settings - Fork 6
2024 Servo
- GitHub issue: https://github.com/Igalia/webengineshackfest/issues/28
mrobinson: Done! Close to webrender in gecko.
mrobinson: Not done, but much better than last year. Now supports for multiple webviews, possible to display in different places in an output surface. Full-featured embedding api like a webview embedding api planned but unfinished.
mrobinson: Build tool called "mach" from gecko, maybe cargo would be better. We still use mach, but we are working towards the possibility of using cargo. The experience isn't great still.
mrobinson: DOM bindings, glue code between javascript code and dom. there is a code generator which exposes........ compiling can require recompiling entire modules which can take a long time instead of fast incremental compilation.
mrobinson: New dashboard of wpt tests for layout. Our new layout system built to support fragmentation from the ground up, is now better than the old layout system. Not complete. Improvements to properly following HTML spec.
Alex: Question about compilation, what does the compilation look like building on rust. Compared to chromium's c++, it parallize a lot, systems for accelerating the build. does this exist for rust?
Nico Burns: Rust has a bunch of incremental compilation built into the tool chain. servo is a lot smaller than chromium. For me a full build takes about 5 minutes.
mrobinson: Implementation of flexbox written in rust, a community project. the question is can servo use these external layout libraries, and what are the opps for reusing code within the larger rust communities. Can we imagine this when working on a browser engine?
oriol: Layout is tied to styling, hard to imagine them as independent.
Nico: I have a pull request for using taffy that makes the style (trait???), the taffy algorithm recieves a type which represents the node in the tree, and there is a type which is returned about the styles. I believe it would be possible a layout layer that does not rely on style and an integration layer that integrates the two.
mrobinson: I do a lot of work that is like maintenance in servo. I've seen where we have tried this before, like font-kit. In general there was a mismatch between what font-kit provided and what servo needs, and that mismatch has gotten bigger over time. To fix a bug is very hard or not possible, it would be a breaking change to the library. another example is stylo, originally part of servo, became part of gecko, we share some parts with gecko like processing files and selection mapping (??). Because people at gecko are working on it all the time, we get the benefits. However if we want to make a change to stylo it's harder to push up stream. Seems like the benefits can only flow to one. Maybe splitting off parts of servo could be good, but might just make us more work. Maybe the convo is around which of those things we use, and which we build ourselves.
Nico: Why did font-kit not work? It's a separate GitHub repo but still a Servo project?
mrobinson: the reason why font kit... a bit in the weeds, but an application that wants to use fonts in rust doesn't need all the things that a browser needs from fonts. For example, do you use the system to rasterize this. Do you use the system font cache -- not needed for other apps, but the CSS spec deines it.
ms2ger: Reusing layout systems from outside the browser-space, what about being able to implement various specs entirely correctly? (?)
Nico: Haven't ran WPT on taffy yet, as they require a scripting engine. Not all edge-cases due to no WPT, but afaik it is compliant. For modern layout (flexbox, grid), maybe masonry/table too there is a clear separation between layout algorithms, which aids maintainability. A general trait for a node in a dom tree, you can ask its size, to lay itself out, etc. Legacy flow layout and inline text is more difficult and maybe it should not be abstracted to the same level.
ms2ger: sounds good that technical there won't be a big issue, but what about the social side, you need the layout engine maintainers to follow the weird spec specifications.
Nico: I am the layout maintainer in this case. I am less comitted to a certain library structure being used, it should follow edge-cases and be performant. Then make it available for use like stylo or webrender. It makes sense to make it maintainable.
Nico: intro. License types: permissive licenses (MIT, Apache); GPL-like (GPL, LGPL) - needs to release source code; MPL (Mozilla Public License) - is inbetween, it is viral like GPL but only to the file boundary. Changing existing files in the library requires source release, which likely is not a big problem for most users but it could cause some companies to avoid it. The Rust convention is to use MIT and Apache 2.0, a lot of (?) projects want to meet that criteria to just have that one license. More of a social reason than legal.
Nico: eg font code, in the Rust ecosystem there are many different libraries for dealing with fonts which divide the general idea into many separate projects; but they share a license so you could take code from each of them. However, due to Servo being licensed MPL this is not possible.
Martin: In general relicensing will be hard because it would require talking to previous contributors to sign a CLA.
Nico: Maybe it should be kept in mind for the future. Tricky spec stuff like tables could be relicensed as permissive.
Martin: In case of tables we start from an existing code-base so we have to talk to the original authors.
Martin: If there are specific things people are interested in, we can approach it a file at a time.
Martin: How difficult did people here (new to) compiling Servo find it?
Olivier: Recently landed their first Servo patch. First-time experience felt painless. Mach instead of Cargo workflow might seem difficult at first, but instructions in the README were clear. Point of struggle was finding interesting issues to work on. Would be interested to triage issues, for first-time contributors.
Martin: Good point, trying to think of how I would get started if I was thinking as a new contributor. We have a good first issue bug tag but it is rarely used.
Nico: There are infinite opportunities in layout code for edge-case/WPT bugs and generally CSS properties that Servo doesn't support. Would be useful to track what we support and what we don't in a document.
Rahki: I would like to mention app unit work that we have been doing. A meta-issue about app unit work might be good but a bit tricky as well for new-comers if wpt test starts to fail. but in general would be useful. People just starting might be intimidated by test failures. Keep an eye on potential easy bugs like refactoring work?
Nico: The Servo book was a good improvement. Had to be careful with his setup when running WPT tests (clang, file descriptor limits). Maybe documenting the workflow would be useful
sideshowbarker: I compiled Servo some time ago and I haven't for a while, I filed an issue about a bug with Mach bootstrap. Build speed is OK compared to WebKit. No issues after that issue.
Jonas: Last time I built it, it was much more painful so good job on cleanup. Interested in issues moving from Mach to Cargo.
Martin: Opportunites around layout, app unit work (mentioned above) and then build (Mach) improvements. Also we have Outreachy students fixing Clippy errors and improving the documentation build. One common point is that it's difficult to work on layout due to its current state (involves large changes). I want to believe in a world where someone can implement a layout feature.
Nico: We are not that far off from the basic layout structure where adding new properties wouldn't be a big task.
Martin: About WPT tests (?). Having a mentor would be good, we should build a culture of mentorship in the community. Is curious if other projects have similar goals in order to improve on-boarding.
Oliver: Mozilla's Bugzilla has a tag for good first issues, and a mentoring field for people to voluntarily assign themselves to help a contributor who is interested in the bug, but having mentors is rare.
Emilio: Mentoring takes a lot of mental energy. Should involve more than one mentor for initial setup.
Martin: Concurs with Emilio. It's a skill on its own, sometimes you feel you could complete the task yourself. It's an investment in the end.
taym: For instance the Spidermonkey integration, we lost the initial maintainers, so it's hard to find mentors in that area.
Martin: GitHub has a file where you can have owners of certain segments of a code-base (wildcards, etc). If a PR touches those files, people automatically get CCd or assigned as reviewers. It could be easier for the review process to define certain people owning set code.
Nico: The bevy project has a similar concept. The have experts in each domain. In Servo feels a bit lost regarding code ownership. Compared to other projects, there are quite a few people working on Servo full-time, but the amount of contributors feels smaller, perhaps due to what happened at Mozilla.
Martin: Other browser engines have the concept of code owners. Any comment about this?
Max: In Chromium we have OWNERS files. It's useful in order to figure out who to ask reviews, in addition to checking the git log. Approval from OWNERS is mandatory. In a few subsystems, the review system can balance reviews across the whole list of reviewers.
Martin: We have a bot, called HighFive.
taym: High-five bot is used to assign the issue when asked, such as "high-five assign me".
Emilio: Servo also had a bot able to cc people (maybe high-five?). Gecko's phabricator has review groups and there is a bot to automatically add some reviewers if some files are touched, but it is intentionally not that strict as it can easily complicate some code-base-spanning changes. You can add non-blocking reviews which do not require a review to get merged.
sideshowbarker: In WebKit, we have an anti-pattern. For DOM events, some reviewers are automatically assigned. Quite often the same reviewers are assigned and likely due to the high volume of notifications they might ignore some of them. In general it takes a while to attract attention. At MDN he doesn't have time to process all emails asking reviews so only relies on the round-robin system. In WPT some attempts were made also to attract reviewer's attention. As a contributor you have to know who to ping for reviews. You can ask in Matrix, if you know where it is. Code owners is not the best experience in WebKit. Works a bit better in MDN.
sideshowbarker: At MDN for first-time contributors, a human person should reach out, congratulate new contributors and be welcoming. People are usually positively surprised by this.
Nico: On that topic, Servo's TSC meetings are open to anyone but the vibe of those meetings is quite different to other meetings I attend. Should we start a community meeting separate from TSC meetings?
Martin: Some projects have "Office hours".
Martin: What are some wild ideas for rendering engines you could see Servo doing?
gregp: The marquee element!
Martin: How can we make Servo the most performant a11y web engine? Can we make a parallel a11y tree?
Emilio: About performance. Are we actively measuring it?
Martin: Right now, no. We are expecting to do it as a goal for next year.
Emilio: Servo might not want to have to deal with some slow quirks of CSS/layout (eg IP splits(?)).
Martin: Often people would ask if by turning some CSS features they would get a more performant engine. It might be something we could consider if you think it's worth. Can you open a bug about this?
Nico: In blitz that's partly what we try to do by making components easy to swap or disable.
Andreu: For quirks mode etc, do mainstream browsers have use counters for those niche quirks? Or is it known if they are used in the wild? An experimental engine with a mode without quirks could be useful for testing the web to see how it is.
Martin: Interesting idea, to disable quirks mode.
Andreu: Behind a flag.
Martin: Tricky as (?) but still doable.
Georg: Browsers are like Operating Systems nowadays. But there are some dedicated use-cases that require dedicate rendering. For instance in Qt there is a similar concept. Another example, a game can require fullscreen by-pass. Giving more control of the rendering pipeline to allow for more scenarios where web engines can be used, eg gaming cross-platform.
Martin: Depends if you are embedding or using the web-engine. You need to setup a hook system, that relates to the embedding API.
Jonas: What if I wanted to compile it without Rust's standard library? Like running it on a $5 micro-controller.
Nico: Servo without allocation would be show-stopper ;)
Jonas: Allocations are fine.
Martin: (?) The argument of do we use dependencies more or do more ourselves.
Nico: Servo has the opportunity to be less monolithic and more modular.
canadahonk: JIT compiler for CSS? WebKit has one I think? (reference)
Emilio: Could make things super fast in some micro-benchmarks. Would decrease maintainibility?
Martin: Thanks everyone for attending, especially the new-comers!
Unused topics:
- Strategy for writing in reviewing changes
- Modularity and Switching JavaScript engine
- Long-term issues with
- Long compilation times
- Event loop
- IFrame loading reliability
- File descriptors