Continuing my efforts to obtain decent performance as I integrate the Argonaut Stack to form the Haphaestus web browser, I’ve now tackled my Harfbuzz language bindings, cutting down on the amount of time copying data into & out of the C library.
As I strive to assemble “The Argonaut Stack” together into the “Haphaestus” web browser, I am facing serious performance problems. One thing that made a big difference (even if its not enough on its own) is to parallelize layout calculation accross multiple CPU cores! Because Haskell made this unusually trivial!
I’ve recently finished implementing Haphaestus’s rendering engine which I named Mondrian, after a dutch artist who liked drawing boxes. This is a GPU-accelerated library for drawing the surrounding backgrounds & borders CSS allows webdevs to add to their pages. Hardware-accelerated text rendering is handled by Typograffiti.
Lists are a powerful way to making complex ideas easier to digest, better than caramel. Auditorily I defined them via a thunk earcon, with or without the insertion of tiered numbering. Visually they’re denoted by preceding each list item by a symbol (•) or number.
Now that Balkón implements line breaking, the next step is to implement page breaking.
Whereas speech, like for Rhapsode, positions text only in the single dimension of time, Haphaestus positions text in 2-dimensional space. This requires a choice of non-trivial formulas across several tree traversals. In a back & forth negotiation regarding how to size elements for your device.
For about two months now, I have been building Balkón, a Haskell library for inline text layout to become part of the Argonaut Stack.
Quick note today after having gone back & fixed Typograffiti to work for more text than my demo.
NOTE This is a personal blogpost from Adrian Cochrane, the opinions expressed within are not necessarily endorsed by other contributors to the Argonaut project. And yes, I wrote this one quickly.
In developing Haphaestus the sites which gives me the most trouble to support are the silos creatives feel expected to publish on. As such it is in my vested interest to question the value of these silos, leading me to self-hosting our own codeforge.
I may be striving for simplicity in my browserengine development, but I will not do so at the cost of inclusivity. As such I’ve spent the past couple months (alongside coordinating a growing project) developing pure-functional language bindings for the best available font libraries covering the widest breadth of written langauges. Namely FontConfig & Harfbuzz. Excellent bindings already existed for LibICU, and I wrapped FreeType in an OpenGL-accelerated renderer.
I am excited to announce: Haphaestus TV web browser has received NLnet funding!
Anonymously retweeting a Twitter thread, which despite its truth got harassed into deletion:
As an upstart browserengine it is my privilege to promise on this International Day Against DRM 2022: Haphaestus will never support Encrypted Media Extensions or any other form of DRM.
Plenty has happened since I last blogged here, including banging my head against Haskell’s text rendering libraries (hoped to be blogging about that…) & rejigging my plans for Rhapsode & similar browser engines. Now I’m actively taking steps towards turning Rhapsode into a decent browser you can install as an app from your package repositories, as opposed to a browser engine waiting for others to build upon. As part of that I’m commisioning art to have something to display onscreen!
I’ve now implemented the core featureset of (save for a HURL crash which badly needs addressing) a Rhapsode bug-compatible webpage debugger, compatible with Selenium & whatever your favourite web browser is. Even Rhapsode, once I’ve implemented forms for it (coming soon)! All the features Selenium expects are implemented, though where they’re not supported by Rhapsode I wrote noops.
Not only can Rhapsode read pages aloud to you via eSpeak NG and it’s own CSS engine, but now you can speak aloud to it via Voice2JSON! All without trusting or relying upon any internet services, except ofcourse for bogstandard webservers to download your requested information from. Thereby completing my vision for Rhapsode’s reading experience!
Modern web browsers are massively complex beasts, implementing an evergrowing mountain of supposedly-open standards few can keep up with. So why do I think I can do better whilst adhering to the same standards? Why do I think that’s valuable?
Rendering a webpage in Rhapsode takes little more than applying a useragent stylesheet to decide how the page’s semantics should be communicated. In addition to any installed userstyles and optionally author styles.
I thought I might start a blog to discuss how and why Rhapsode works the way it does. And what better place to start than “why is Rhapsode an auditory web browser?”