In 2006 we started writing a clean room SVG browser, primarily targeting set-top boxes. Back then, user interfaces were written in native code (usually ugly and inflexible) or HTML (very slow). We emphasised how it was equivalent to a web browser but, rather than an HTML parser with CSS box model layout, we parsed SVG markup. SVG takes negligible time to lay out and uses CSS sparsely, so we massively outperformed HTML browsers on equivalent UIs.
Thanks to it having a small code base, we were able to integrate hardware acceleration very early on. STB chipsets have had 2D blitters capable of quality scaling for years, and we could support animations on cached areas of the document/screen easily and achieve 25fps (considered fast for the time). This performance has meant that tens of millions of STBs have shipped using our SVG browser.
It was always clear that, while SVG was actually more suitable for UIs, HTML was what the industry wanted to use because of the momentum from the web world. We started investigating HTML functionality embedded in SVG (as XHTML) for two reasons – it would allow better layout of text for UI designers, and it would enable us to run W3C test suites that test non-HTML features more easily.
Ironically, while the number of HTML browser engines has decreased, the quality of the specs has dramatically improved allowing new browsers to come along and be compatible with the vast majority of sites. Historically the HTML parser was impenetrable but, thanks to the huge efforts of the WHATWG team, it’s now possible to parse HTML identically to all other browsers.
Once we started making progress with the W3C box model features we had to make a decision on whether to continue with HTML development. It was clear that to do so would need a differentiator when compared to other browsers, and since our reputation was for performance, we needed to decide how we could be fast but compatible with HTML.
STB chipsets tend to be very price-competitive largely because STBs are often given away at little or no cost. They are not comparable to chips in desktop computers, and have only in the last few years switched to multi-core with OpenGL. Back in 2012, Mozilla’s Servo project had started hitting headlines about multithreaded, parallel algorithms, and we decided to see if we could do similar, initially targeting our historic market of STBs. As I’ve said, we always claimed our SVG browser was a web browser without the HTML, and this would become a good test of that claim.
I wouldn’t say it was easy, but we now have an HTML browser engine that is fast (60fps), multithreaded, GPU-accelerated and able to render a growing set of HTML UIs (and web pages) flawlessly. There’s plenty more to do, and plenty more to detail in future blog posts.
If you’d like to automatically receive our posts by email please join our mailing list.
