Porting Epiphany to Managarm
Post written by Dennis Bonke.
Introduction
Modern web browsers are among the more demanding applications an operating system can run. They exercise graphics, networking, multimedia, process management, and plenty of obscure system interfaces along the way. For an operating system like Managarm, which aims for source-level compatibility with Linux software, getting a browser running therefore makes for a useful compatibility milestone.
Recently, we reached that milestone by getting GNOME Web, also known as Epiphany running on Managarm.
Why Epiphany?
Epiphany isn’t one of the first browsers people think about when choosing a browser. Chromium or Firefox (or their derivatives) are much more common. We chose Epiphany for the simple reason that porting Chromium and Firefox is much more involved, and given that we already run WebKitGTK, it made a lot of sense to continue on this path. It is also a capable, full-fledged browser, making it a suitable target for Managarm.
What we did
We already had WebKitGTK running through MiniBrowser, its demo browser, so we expected the initial port to be fairly easy, and that most of the time would go into improving performance. It turned out to require the GTK4 backend for WebKitGTK, which we did not have yet; this required several new ports and updates to some existing ones. We ran into some cross-compilation issues with blueprint-compiler, which is used by Epiphany. Because GTK-based applications normally refuse to run as root, we switched the default user from root to managarm (PR: #743). Finally, we fixed the post-install scripts for some Epiphany-related packages (PR: #760). Once Epiphany was running, most of our effort went into improving its performance.
Trying to get to Linux performance levels
On one of the first timed runs, Epiphany startup took about a minute on a clean boot. That is obviously unacceptable: on the host machine, a comparable cold start on Linux took about 9 seconds, while the Managarm test was running in a virtual machine. We traced much of the delay to the built-in ad blocker: disabling it significantly reduced startup time. Since we wanted to keep the ad blocker enabled, we started investigating why this was so slow. It turned out that our file I/O had plenty of room for improvement compared to Linux, mostly because Linux has several layers of caching in its block stack. Other work in this area involved running less work while holding filesystem-related locks (#1550, #1552 and #1593), multithreading the block server (#1549, #1560 and #1592), improving the virtio-block driver itself (#1558 and #1561), adding caches (#1559, #1582, #1589, #1590 and #1606) and making other filesystem and writeback improvements (#1555, #1576, #1594, #1596, #1597, #1611 and #1613). These improvements are great for the system as a whole, and brought down the cold startup time to around 15 seconds with the ad blocker enabled.
Trying to play video
With the performance gap substantially reduced, our attention shifted to playing a YouTube video. We already had an initial Intel HDA driver, so we could aim for complete playback, including audio. Video decoding itself does not depend on Intel HDA, but without an audio output device, a YouTube test would be incomplete. Unfortunately, our GStreamer stack needed more work to enable the correct plugins, which also involved a port of FFmpeg for the libav plugin. That resulted in working video playback, but no audio. Debugging this took most of the time, as this involves interactions between our audio driver, WebKitGTK, the GStreamer stack, PipeWire and WirePlumber. Eventually, it turned out to be a problem in upstream PipeWire that we worked around while upstream is fixing it properly (PR: #767). While audio is now supported, the audio servers do not start automatically on login yet; further fixes to the audio stack are still needed.
Where are we now?
As it stands, the browser is usable for everyday tasks we’ve tried, including browsing GitHub, Gitlab and Codeberg, reading your email, using the Discord web application, using Matrix (Element web client), IRC (The Lounge IRC bouncer) and Fluxxer, watching YouTube, using ChatGPT and playing games. Voice calls are unfortunately not supported by Discord on this platform, so Discord is limited to text chat for now.
Supported by NLnet
This project was funded through the NGI0 Commons Fund, a fund established by NLnet with financial support from the European Commission’s Next Generation Internet programme, under the aegis of DG Communications Networks, Content and Technology under grant agreement No 101135429. Additional funding is made available by the Swiss State Secretariat for Education, Research and Innovation (SERI).
Talk to us
We welcome contributions to Managarm! If you want to help out, feel free to look at our issue tracker, or chat with us on Discord or IRC in #managarm on irc.libera.chat about ideas.