Devblog: Fixed point vs floating point

I had an interesting problem with one of the sites I tried loading a while ago. weibo.com was using jQuery (version 1.7.2) which tries to detect browser features, and decided Flow was actually Internet Explorer. It later tried to use IE-specific filters rather than CSS opacity, so no fades worked. I tracked this down to jQuery’s startup code setting opacity to 0.55 and then getting it back out again. Since we converted 0.55 into 16.16 fixed point too early, it was retrieving it as 0.549988. That wasn’t equal to 0.55, and so jQuery decided Flow didn’t support opacity and therefore must be Internet Explorer.

Browsers use fixed point maths internally for storing the results of many calculations. Often 26.6 bits, which gives 64 positions between (CSS) pixels, or 24.8 bits to give 256 levels of anti-aliasing in graphics.

Our initial design for CSS style tried to use the most applicable value possible, so for the width property we would store the parsed value as 26.6 precision but SVG values would often use 16.16 precision (the SVG Tiny 1.2 spec suggests this).

Smooth animations with CSS will-change

In user interfaces it is very common to apply animation effects in response to user input. Some of the most common effects involving fading, sliding or zooming UI components in or out to redirect the user’s focus. In HTML/CSS this is typically achieved by modifying the opacity and transform CSS properties, by using CSS transitions, CSS animations or Javascript. What you may not realise is that setting these properties can have unexpected effects on the rendering order, and even the layout of HTML elements.

How can UIs keep up with higher resolution video?

If you buy a new TV today, the chances are it is 4K. It’s quite strange that the UIs on these TVs are still rendered at 1080p and upscaled, but that’s the reality. It means that any text and graphics in the video stream, such as football scores, are visually sharper and clearer than the TV’s own menus and app UIs.

How we test a browser

Browser testing has come a long way in the last 15 years. Back then I worked for a small embedded browser company with a test team that manually checked websites. This was tedious, and inefficient as there are only so many sites a person can visit in a day.

When I joined Ekioh, I was pleased to see they had taken a more modern approach from the start. There was a genuine passion for product stability and a strong desire to avoid the embarrassment of regression bugs.

More detail on the MotionMark test results

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.

Devblog: Filling vector paths on the GPU

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.

Does a multithreaded browser use more power?

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.

Devblog: Rendering HTML/CSS on the GPU

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.

Devblog: Google Mail in a clean room browser

Google Mail (Basic HTML) screenshot

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.

Devblog: From SVG browser to HTML browser

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.

Developing a faster browser engine

In 2012 we started an ambitious project to develop a new browser engine that would deliver excellent performance on embedded devices and consumer electronics. Mobile phones aside, consumer electronics products are usually designed with the smallest possible bill of materials required to deliver the desired user experience. A good example of this type of product is the TV Set Top Box (STB), these are often cost subsidised by TV network operators and in some cases are given away free.

Since consumer electronics product designers are always striving to get the best performance they can from every component they use, we set ourselves the goal of delivering significantly higher performance than any other browser could offer. This wasn’t a naive aspiration, in the 6 years prior to starting the project, we’d developed the world’s fastest SVG engine and had significant experience in managing a rapidly evolving browser product base from our work with WebKit.

Mainstream STB silicon was just starting to include a GPU. It was clear, even at that time, that the GPU would soon become commonplace in CE silicon so we decided to execute all our rendering code on the GPU. Efficiently using the GPU offers the prospect of high frame rate animations and smooth UI transitions which were notoriously difficult to achieve on an STB. Also, running the rendering code on the GPU helps ensure CPU availability for all the browser’s non-rendering tasks.

Back then, single core CE silicon was also just starting to be replaced with dual core. Whilst each individual core was often a little slower than the single core product it replaced, overall processing power increased. It seemed logical to assume CE developments would continue down this evolution path, following the footsteps of the more powerful desktop processors which were already well into multicore territory. We focused our ideas for a multithreaded layout engine to match this multicore trend.

Some of our early thinking was shaped by the parallel web page layout research done by Meyerovich & Bodík. That research also influenced the Servo project which was started by the Mozilla foundation around the same time that we started developing our multithreaded browser.

Writing multithreaded software has its own unique set of challenges to ensure two threads don’t both manipulate the same data structure at the same time. Careful design ensures that laying out text in one part of the DOM tree has no requirement to access another part of the DOM tree. We strictly adhere to this practice which has helped ensure thread safety by design. Using ThreadSanitizer (TSan) as part of a continuous build system, coupled with automated stress testing on a variety of machine loads has helped ensure a mature code base where any threading issues are quickly spotted and addressed.

The first release of our multithreaded browser, Flow, was announced on 1st May 2018. As we’d hoped, Flow’s animation performance on multicore CE silicon outperforms WebKit and Blink. We now have the big task of implementing the rest of the features expected in a modern browser.


If you’d like to automatically receive our posts by email please join our mailing list.