Ekioh’s multithreaded HTML browser is rapidly making a name for itself as being the fastest browser available. Whilst Blink based browsers like Chrome currently dominate the market, they might not be the best choice for application and middleware rendering. As the MotionMark benchmark confirms, Flow’s performance is streets ahead of the competition.
Since starting work on Flow, our focus for the rendering engine has been on HTML/CSS. The number of basic shapes and painting styles used in HTML/CSS is quite small, which has allowed us to create a highly specialised engine using the GPU for all painting tasks. We’ve also supported elements in Flow for a while, but until recently all canvas rendering was performed on the CPU.
Because of the great efforts of the Cern WorldWideWeb Rebuild team, I thought I’d try the original browser layout engine inside Flow, the newest browser layout engine.
Recently I was discussing Flow, our multithreaded browser, with a friend of mine who questioned whether a browser using all the cores would be beneficial in battery operated products like their new smart watch. This prompted me to do some research and the results were surprisingly in favour of our multithreaded approach.
When rendering web pages most browsers use a general purpose graphics library to do all their drawing. For example Chrome uses the Skia graphics library. This makes sense for cross platform browsers since they can use a single drawing API and leave the implementation details to the graphics library. The graphics library can try to optimise the drawing operations using some platform specific 2D hardware acceleration, or using a 3D library such as OpenGL/DirectX to take advantage of the GPU. If there is no hardware acceleration available the graphics library can do all the drawing in software using the CPU.
Flow only recently added limited HTML form support and that lets us log into Google. We hadn’t concentrated on forms as they’re barely, if ever, used in TV UIs and there was plenty of other stuff to get on with. Pleasingly, Google Mail (Basic HTML version) rendered very well the first time we were able to log in. Full Google Mail doesn’t work yet, but it makes sense to start with the basic mode first.
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.
I’ve just finished reading the recent 2018 Nagra/MTM Pay-TV Innovation Forum report. It’s an in depth document comprising 44 pages of data and insight into the evolving world of TV and the challenges that the industry faces.
OrangeMark is one of a handful of benchmarks that focus solely upon rendering performance. It’s comprehensive and covers 40 rendering techniques including some which are rarely used in modern UI design. Here we’ve drilled down to look at performance for the most commonly used subsets.