ekioh Registration and Sign Up Information | ekioh

View this email in your browser

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).

This made sense when we were targeting CPUs without floating point with our SVG Engine, but nowadays everything that is expected to run in a modern browser has hardware floating point support - especially if they come with OpenGL ES. Various web platform tests check the calculated results of properties in ways that require us to store them using floating point - at the very least, it's a reasonable assumption to expect that getting a value from JavaScript would return the value you set in the first place.

Switching to floats, instead of storing values in three different precisions, simplified most of our style getters and removed lots of legacy code. For a few properties, it may be trivially slower, but the precision gains for compatibility with JavaScript libraries, meant it was necessary and probably sensible anyway.

Different sites and JavaScript libraries use many different methods for browser detection. This version of jQuery is pretty ancient, but it's a useful demonstration of incorrect assumptions that can be made from one function call that can cause strange behaviour later.

Copyright � 2019 Ekioh Ltd., All rights reserved.
You are receiving this email because you are on Ekioh's DevBlog mailing list. We maintain separate mailing lists for each category of information, enabling you to tailor the information we send you by subscribing or unsubscribing from each category.

Our mailing address is:

Ekioh Ltd.

17B Sturton St

Cambridge, CB1 2SN

United Kingdom

Add us to your address book

Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list.

Email Marketing Powered by Mailchimp

View this email in your browser

Ordering from Amazon using Flow

Being a big fan of online shopping, I�ve been keen to see when Flow could successfully complete a transaction on amazon.co.uk. It�s fair to say that online shopping is not a target use case for Flow, so I wasn�t going to get any engineering time dedicated to this; instead I was relying upon the product�s ongoing development to do the job for me.

When I first tried the site over a year ago, Flow�s lack of HTML form support made it unusable, and there were a few rendering issues. Over time, development not specifically targeted on Amazon has largely fixed these issues. Towards the middle of last year, the opening screen was looking pretty good, but the inability to search or login meant the site still wasn�t fully usable.

Once limited form support was added to Flow it was possible to search for items and successfully place them into a shopping basket, but login still didn�t work. At the end of the Amazon login process there is a permanent redirect (HTTP 308) and Flow wasn�t dealing with it correctly.

All the login info could be entered but when you clicked Sign-In, Flow displayed a 308 error page rather than the Amazon home page. Manually reloading following the error page took me to the Amazon home page where I was surprised to see that I was signed in. It therefore appeared that the whole login process was getting tripped up at the last stage.

As soon as I knew our engineers had succeeded in getting Gmail working in Flow, I decided to re-check Amazon. It turned out they had encountered a similar problem with the Gmail login process. Flow was failing to send the HTTP POST data in the follow up request after the 308 response and so when they fixed that, the Amazon login process also completed correctly.

To celebrate this achievement, even though no one had actually focused their attention on making Amazon work, I used Flow to buy a big bag of sweets from Amazon for the team to share - not healthy, but fun.

Copyright � 2020 Ekioh Ltd., All rights reserved.
You are receiving this email because you are on Ekioh's DevBlog mailing list. We maintain separate mailing lists for each category of information, enabling you to tailor the information we send you by subscribing or unsubscribing from each category.

Our mailing address is:

Ekioh Ltd.

17B Sturton St

Cambridge, CB1 2SN

United Kingdom

Add us to your address book

Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list.

Email Marketing Powered by Mailchimp

View this email in your browser

Can we fix it?

Last month we were shown a new HTML UI from one of our embedded partners. When displayed in Flow, it showed a button with text incorrectly displayed over an icon. We''ve known for a while we had a few problems with buttons as many of them were the wrong size, or their content wrapped too soon. This gave us a good reason to investigate them all.

It turns out, the contents of Flow's buttons were laid out as if everything were a flex item, not quite following the spec. Since flex items can not float, any button with a float inside would render incorrectly.

Buttons are used far more often than I'd expected and pleasingly, with this fixed, many sites looked far better. The Guardian and eBay now render their down arrows in the correct place without strange wrapping, and The WorldWideWeb Rebuild now renders its missing title bar icons.

As this button fix showed major layout improvements on many of the websites we have blogged screenshots of, it seemed a shame to not fix the remaining layout bugs.

After the buttons were fixed, all the alignment and sizing layout bugs at the top of YouTube had gone away. It has a problem with search results, but the only remaining problem with the rendering was a few centimetres of whitespace below the video, above the title. YouTube's stylesheet is enormous and it at first appeared to be a CSS variable or a flex bug. After a lot of test-case trimming, it turned out to be that we hadn't yet implemented percentages inside CSS calc() when applied to padding properties, in this case, padding-top: calc(9/16*100%). Helpfully, that code had been written a while back but hadn't then been tested enough to commit.

Outlook demonstrated the most bugs in Flow but some were trivial fixes once we understood the problem. The horizontal alignment of each email subject was down to incorrectly subtracting the padding twice from the flex-basis size. The PDF icons had an enlarged grey background because of a problem with box-sizing: box-border when calculating the intrinsic sizes. Both took far longer to figure out what the problem was, than to fix it.

The magnifying glass in the search icon was too low, which turned out to be another flex bug ('the main size of a fully inflexible item with a definite flex basis is, by definition, definite'). We also didn't support placeholder text on input elements which needed shadow trees to be mostly implemented. After that, we found the ''Search'' text was in the wrong colour which was due to Outlook''s CSS not using ::placeholder, only the various vendor prefixes.

Finally, Twitter has a redesigned page since we last took a screenshot so it's hard to know if the original alignment issues on there have been fixed or not. The new page had some problems that we had to fix. The search box in the top right was missing (actually off the right edge of the window) and each tweet's date was vertically aligned incorrectly. The search box was off the side because it is absolutely positioned and positioned in relation to an incorrectly calculated static position. The incorrect date alignment was because the baseline code was skipping the baselines of flex containers.

For regular updates on our progress, please follow us on Twitter.

Copyright ? 2020 Ekioh Ltd., All rights reserved.
You are receiving this email because you are on Ekioh''s DevBlog mailing list. We maintain separate mailing lists for each category of information, enabling you to tailor the information we send you by subscribing or unsubscribing from each category.

Our mailing address is:

Ekioh Ltd.

17B Sturton St

Cambridge, CB1 2SN

United Kingdom

Add us to your address book

Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list.

Email Marketing Powered by Mailchimp

View this email in your browser

Because of lockdown we're all working from home at the moment so my access to hardware is somewhat limited. On a whim, I decided to try Flow on my Amazon FireTV Stick and was a little surprised to find it wouldn't run. I grabbed some logs and asked colleagues what they thought the problem might be. They were able to quickly spot what the issue was and they gave me a build to test within a few hours. Armed with a working version I thought I'd see how Flow compares with the other browser options that are available.

Browser performance on a second generation FireTV Stick

Apart from Amazon Silk, there aren't that many browser options for the FireTV Stick on their app store. It also became apparent that the latest version of Firefox for FireTV that is available is a Firefox UI on top of the OS's inbuilt WebView. To get a good browser lineup for comparison, I sideloaded Chrome, a simple WebView tester and Flow.

The graphics benchmarks I chose were MotionMark and OrangeMark as between them they give a good overall picture of performance for animating with both HTML and canvas. I used JetStream to look at JavaScript performance as it combines aspects of many other benchmarks to give a good overview.

Each benchmark was run three times and the table shows the average, in all cases higher scores are best.

OrangeMark works by doubling the complexity of the test up to ten times; this means a browser scoring 6/10 is twice as fast as one scoring 5/10. The OrangeMark results show that Flow is nearly eight times faster than WebView for 2D graphics. For HTML canvas, Flow still has the edge, but it's a narrow margin as there are still some areas we haven't yet accelerated on the GPU.

MotionMark's results also echo my general feeling that Flow is around twice the speed of other browsers on the STBs that we use in the office.

Flow uses the SpiderMonkey JavaScript engine from Mozilla which, as the JetStream benchmark shows, is able to hold its own compared to the V8 engine which the other three Blink based products use.

Why do these figures matter?

Many applications and UIs are written in HTML as it makes them much easier to create for multiple operating systems. For these, a faster browser means a smoother and more responsive UI. A faster browser also lowers the minimum CPU requirements for an acceptable UX.

A reduction in CPU requirements can make products less expensive and more attractive for customers. This opens up a larger potential market for service providers, such as OTT video operators, who target those products.

For app developers, lower CPU requirements also increase the number of products they can target. With the varying performances of the wide range of Android based hardware being used, having a faster browser to render apps makes them significantly more appealing.

Ultimately, Flow's ability to get more out of less means costs can be saved and margins maintained.

Copyright ? 2020 Ekioh Ltd., All rights reserved.
You are receiving this information because you are on our news & posts mailing list. We maintain separate mailing lists for each category of information, enabling you to tailor the information we send you by subscribing or unsubscribing from each category.

Our mailing address is:

Ekioh Ltd.

17B Sturton St

Cambridge, CB1 2SN

United Kingdom

Add us to your address book

Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list.

Email Marketing Powered by Mailchimp

View this email in your browser

3D Environments in CSS

Flow's rendering of https://keithclark.co.uk/labs/css-fps

When I was first implementing support for 3D CSS transforms in Flow a couple of years ago I came across a Web demo by Keith Clark which created an entire 3D environment purely using CSS: https://keithclark.co.uk/labs/css-fps.

The way it uses CSS to create not only the 3D geometry, but also lighting and shadow effects is very impressive. Unfortunately this didn't work very well in Flow because our support for transform-style: preserve-3d was minimal. This meant the ordering of elements in the scene was incorrect and visually confusing. I thought it would nice to get this demo working and complete our implementation.

For trees of html elements with transform-style: preserve-3d, the elements all share the same 3D space and their rendering order is no longer defined by their location in the DOM, but instead by their z-position in 3D space.

If we take a simple example of 3D transforms:

<body>
<div class="parent">
<div id="A">A</div>
<div id="B">B</div>
<div id="C">C</div>
</div>
</body>

With styles of:

.parent { transform-style: preserve-3d;
transform: translate3d(0,100px,-300px); }
#A { transform: translate3d(0,200px,100px); }
#B { transform: rotateX(0deg); }
#C { transform: translate3d(0,-200px,-100px); }

then the rendering order will be quite simple: #C should be rendered first since it has the lowest z-coordinate of -100px, followed by #B with 0px, and finally #A with a z-coordinate of 100px. Sorting items by their centres' z-coordinates is very simple, and is often good enough to render a 3D scene, especially if items are all similar size. But we can easily break that ordering, for example rotating item #B. If we have a rotation of 70 degrees suddenly the rendering order must be exactly the opposite of the previous order, even though the z-coordinates of the items have not changed. This is because item #C now obscures item #B, and #B obscures #A. See the image below to visualise this.

Even more complicated case occurs if we rotate #B by 50 degrees. Now #B intersects both #A and #C in 3D space. Now the rendering order must be: the back part of #B, then #C, then the centre of #B, then #A and finally the front part of #B.

Since Flow renders everything on the GPU using standard 3D graphics APIs my initial plan was to implement this using a technique that 3D games typically use, namely depth-buffering. In this method a screen pixel buffer is used to store the depth of items for every pixel on the screen. Then items can be rendered in any order, but only pixels with a smaller z-value will be drawn to the screen and to the depth buffer.

However the main problem with this technique is that it does not work with alpha-blending, required for edge anti-aliasing, and for rendering items with transparency. When games use anti-aliasing they typically use other techniques, such as multisampling, which don't require blending. However the overall rendering quality is not as good as that expected of a browser. Games typically try to limit the number of items with transparency and then render them separately in the correct order. However they do not handle the case of transparent items intersecting other items, and content authors must prevent this happening. Since in CSS having transparent intersecting elements is allowed, the direct approach is required, and we need to split elements into different parts along the lines of intersection with other elements.

The algorithm suggested by the CSS transforms specification for sorting items in a scene is given by Newell's algorithm and is described in detail in the original 1972 paper. Essentially we start with a list of element items sorted by their z-coordinates, and then do extra checks on each element to decide whether they obscure any items with greater z-coordinates. If they do then the items are reordered, and the same tests are performed with the new ordering. If an item is moved more than once then items must cyclically obscure each other, such as when they intersect each other. In that case the items are split up into pieces, and added back into the list to be sorted separately.

It was quite challenging to implement the algorithm efficiently, especially dealing with the 3D maths to test whether items obscure each other, and to split the items into polygons when they intersected. However the final result was very satisfying, and Flow manages to render the scene without any glitches at a solid 60 frames-per-second.

However, looking closely at some of the objects, in particular the pipes, there are some rendering artefacts which are not present in other browsers. They are divs with 3D transforms applied, and these divs use multiple background layers. Flow renders both 2D and 3D transformed elements directly to the screen, unlike other browsers.

Anti-aliasing in browsers is typically implemented by alpha-blending against the background using partially transparent edges. Browsers use this technique for almost all rendering, including fonts and transformed elements. One downside of this technique is when edges overlap exactly, the color from layers below can leak through this partially transparent edge. The left hand image below shows a browser rendering of two touching 2D transformed divs having two background layers: a black layer on top of a red layer. Text also suffers from the same problem, so to demonstrate this the text in the image shows white text on top of green text. The red colour can be seen leaking through the edges of the divs, and the green colour can be seen through the edges of the text.

When a 3D transform is applied to the div, most browsers will no longer have any red around the edges, as shown on the right hand image below. This is because they render it without a transform into a newly allocated layer, and then that layer is rendered with a 3D transform. This has the bonus that any colors from layers below will be obscured correctly on edges, but doesn't solve the more common cases of 2D high-quality antialiasing and of text.

The edge rendering artefacts in the demo happen because Flow renders 3D items in the same way as 2D items: directly to the screen, meaning we get the same artefacts on edges as other browsers have in 2D rendering. This was a conscious design choice as we wanted to avoid allocating a layer for every 3D transformed element which can have a massive impact on memory usage. For example, when rendering this demo at 4K resolution, Flow uses around 7MB in static GPU textures, and depending on the viewpoint, 50-100MB in temporary GPU surfaces (to deal with lots of intersecting geometry). When using the Frame Rendering Stats tool in Chrome, the GPU memory usage is shown to be anywhere between 200-600MB depending on the viewpoint. Flow's approach to 3D is possible because its rendering engine is designed around the GPU, and we've tried to ensure that everything that can be rendered in 2D can also be rendered in 3D. This means that rendering 3D effects in Flow is viable even on embedded devices with limited memory.

Although, in this instance, the pipes in the demo can look worse than in other browsers, the walls and floors look better in Flow. Flow renders images using trilinear filtering instead of the bilinear filtering used by other browsers, smoothing out the pixels in the distance. When panning around the view, this prevents pixel artefacts popping in and out.

To see all our posts please visit our blog page.
For regular updates on our progress, please follow us on Twitter.

Copyright ? 2020 Ekioh Ltd., All rights reserved.
You are receiving this email because you are on Ekioh''s DevBlog mailing list. We maintain separate mailing lists for each category of information, enabling you to tailor the information we send you by subscribing or unsubscribing from each category.

Our mailing address is:

Ekioh Ltd.

17B Sturton St

Cambridge, CB1 2SN

United Kingdom

Add us to your address book

Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list.

Email Marketing Powered by Mailchimp

View this email in your browser

Design Trends

At Ekioh we're regularly looking ahead to see what browser features are set to become popular. As part of this, I've recently spent some time reading the future design predictions from a number of web designers and design houses. As you might suspect there are some wacky ideas being peddled, but on the whole, most designers seem to be agreeing on a few concepts and techniques that look set to shape the way websites and product user interfaces will evolve over the next few years.

The most common theme in the predictions was an increase in the use of layering and soft shadows to give greater depth and make the UX more engaging. As you move around, layers dynamically move into view, often overlapping other elements giving the perception of depth.

For some site designs and definitely for UI backgrounds, stock images and photos are also beginning to lose their appeal. The prediction is that these will be replaced by full screen background video in some cases, and by multicolor gradients in others. Personally, I can see multicoloured gradients being more suitable for UI backgrounds, especially on devices where connectivity and processing performance wouldn't support full screen background video.

Images are also predicted to be supplemented with animated line art. Some sites and UIs will feature high resolution photos or static images that will be brought to life with overlaid line art. I think this type of compound image effect will be most popular when seeking to tell a story or place an animated graphic into context - like the moving parts of a machine overlaid on an image of that machine on the workshop floor.

Whilst Flow's feature set is still rapidly expanding, it's comforting to know that it is already capable of meeting the projected demands of the latest trends. It's always been our goal to be the fastest and most hardware efficient browser engine on the market, so designers can rest assured that using some of these more processor hungry techniques isn't going to make their products more clunky to use.

For regular updates on our progress, please follow us on Twitter.

Copyright ? 2020 Ekioh Ltd., All rights reserved.
You are receiving this information because you are on our news & posts mailing list. We maintain separate mailing lists for each category of information, enabling you to tailor the information we send you by subscribing or unsubscribing from each category.

Our mailing address is:

Ekioh Ltd.

17B Sturton St

Cambridge, CB1 2SN

United Kingdom

Add us to your address book

Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list.

Email Marketing Powered by Mailchimp

View this email in your browser

Flow browser passes the Acid tests

The three Acid tests have a long history; they really started the push for browser compatibility that is now driven by the Web Platform Tests project. Having finished Flow's support for full Google Mail, Acid3 seemed like another interesting target.

Gecko, Webkit and Blink (and, not forgetting, Presto, Trident and EdgeHTML) have obviously passed these three tests for years, but they still are very useful stress-tests for new browser engines. For us, passing the original Acid1 test was useful early on to demonstrate to ourselves that our proof of concept layout code was taking the right approach. Acid2 was much trickier and took a lot longer, but it was a useful milestone for our layout engine. Acid3 focuses more on JavaScript APIs than layout, although it is equally challenging to pass.

A quick note about the score: Acid3 dates back to 2008 and the web platform specs have changed over time so a perfect score, using the version hosted on acidtests.org, is now only 97/100. The version hosted on the web platform tests site has been updated to match the specs and so, using that, browsers should score 100/100. Similarly, on all browsers, Acid2 on a retina screen renders slightly differently, so the image above was taken on a non-retina display.

Acid3 comprises a number of subtests. When fixing a failing subtest, we took the approach of trying to pass all the Web Platform Tests it covers, though that was not always possible as some tests require unrelated features. Acid3 stress tests corner cases for a range of features and APIs, but isn't very broad with its testing. We could have been cheeky and just implemented the specific features needed to pass each subtest, which would have meant we could have passed a long time ago, but that wouldn't really help us in the long run.

A number of the subtests were for Range which we hadn't implemented, HTML forms where our API was minimal, and the CSS Object Model (CSSOM) which we had essentially no support for.

We also had many bugs to fix - a few asserts, a redraw problem where the score was only displayed after resizing the window, our support for CSS pseudos like :nth-of-type() was buggy, and we didn't follow the HTMLObjectElement's fallback rules correctly.

Our goal for Flow is to render websites correctly the first time that anyone tries them. Most of the Acid3 subtests are going to make a real difference. In particular, implementing the CSSOM caused a massive reduction in unhandled JavaScript exceptions reported by our nightly web crawling based testing. Most of those websites, understandably, assume that APIs dating from the 1990s are implemented, and don't fail gracefully if they are missing.

It feels like quite an achievement in making Acid3 pass. No new browser engine has managed this since its creation over 12 years ago. Many fell by the wayside reflecting the complexity of the Acid tests. We are still implementing APIs so Flow will behave perfectly on more and more websites, and each milestone like this helps with its compatibility goals.

Copyright ? 2020 Ekioh Ltd., All rights reserved.
You are receiving this email because you are on Ekioh''s DevBlog mailing list. We maintain separate mailing lists for each category of information, enabling you to tailor the information we send you by subscribing or unsubscribing from each category.

Our mailing address is:

Ekioh Ltd.

17B Sturton St

Cambridge, CB1 2SN

United Kingdom

Add us to your address book

Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list.

Email Marketing Powered by Mailchimp

View this email in your browser

Isn''t it nice when things just... work?

Back in 2003, Honda released Cog. It was an amazing advert. I even ordered the free DVD - there was no YouTube back then. If you haven't seen it, it's worth watching - it has no CGI and no smoke and mirrors. It, apparently, took 606 takes.

Flow, on the other hand, has to work well, if not flawlessly, first time, on all sorts of web sites we have never seen before. Increasingly often, I'm pleasantly surprised when I try a new website and it works pretty well, despite us not having spent any time investigating or fixing bugs specifically for it. Here are a few I've tried since we made the Acid tests pass:

YouTube renders mostly correctly, and now functions well, despite us spending next to no effort on it. It's fair to say we have automatically tested loading the home page daily for several years to ensure it doesn't crash but, until now, not interacted with it in any substantial way.

Microsoft Outlook is, perhaps, a better example. As far as I'm aware, no one in the team tried loading Outlook until yesterday, but it seems to work very well, though it has a few alignment issues. I sent my first email, using Flow, to myself without problems. I'm particularly impressed with this as it's probably just as complex as Gmail, yet is mostly functional with all the animated menu effects.

Another site I tried is Tom's Guide. I found it when experimenting with using Flow as my primary browser and was looking for a new vacuum cleaner. It rendered well, but a few paragraphs were incorrectly styled. I noticed, on the console, it needed performance.mark() which happens to be the feature I'm currently working on. Trying it in my development tree fixed that console error and all the styling problems had gone away - it turns out it programatically loads a stylesheet, but the uncaught exception was stopping this.

eBay is also a good example of a page that I've never tried using properly in Flow before. It has very few minor rendering issues, but I can navigate around, search for products, and I've just bought a pair of brake blocks for my bike, all without any problems.

Most other sites still have a few rendering issues - icons missing or incorrectly vertically aligned, or a bit too much whitespace here and there. They obviously do matter, but we can address these later - if, indeed, they haven't gone away in the process of debugging a different website.

I'm not claiming Flow is able to work well with all websites yet, certainly each of the above has some rendering issues. It is still some way off being able to be used as a general purpose web browser, but I am regularly surprised, sometimes amazed, when I find a complex web page that looks and works so well, the first time I try it.

Copyright ? 2020 Ekioh Ltd., All rights reserved.
You are receiving this information because you are on our news & posts mailing list. We maintain separate mailing lists for each category of information, enabling you to tailor the information we send you by subscribing or unsubscribing from each category.

Our mailing address is:

Ekioh Ltd.

17B Sturton St

Cambridge, CB1 2SN

United Kingdom

Add us to your address book

Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list.

Email Marketing Powered by Mailchimp

View this email in your browser

Is the wider appeal of HTML being eroded?

For a while now, people have been expressing concern about Chrome's dominance creating a browser monoculture. With Microsoft's recent switch to Chrome, the choice of rendering engine was effectively reduced to Blink (Chrome), WebKit (Safari) or Gecko (Firefox). Whilst there are a large number of browsers for desktop and mobile users out there, almost all are based on Blink/Chromium.

As well as displaying web content, HTML browsers are used in a wide variety of products for application and user interface rendering. The potential effect of one company dominating the implementation of the standards is that they are biased towards web page rendering, their largest use case. Focusing solely on web content could limit the wider appeal of HTML.

Domination stifles innovation

All three main browser engines are developing at a rapid pace, but some aspects have barely changed since they were first written. Blink, WebKit and Gecko are based upon layout architectures which are single threaded, with some aspects dating back to the nineties when single core processors were commonplace. Being single threaded means that the rendering engine isn't making full use of multi-core processors.

Today's browsers now use a multi-process architecture where each page can be allocated its own process. The multi-process model means that if any one page stalls, the others are unaffected, but it does little to improve the performance of single page rendering. Unfortunately, for user interfaces, it is single page performance that matters and the restrictions of single threaded layout can impact the user experience.

For most people with fast computers or phones, layout speed on the open web is fast enough. Because of this, there is little motivation to make large scale architectural changes to improve layout performance, especially when these changes would disproportionately benefit the minority use cases.

Moving beyond a single thread

During the last ten or so years, various groups recognised the limitations of a single threaded architecture, but developing a multithreaded browser isn't a straightforward task. Multithreaded layout is not something that can easily be retrofitted to an existing rendering engine design. That's not to say that people haven't been thinking about it:

Fast and Parallel Webpage Layout by Meyerovich & Bodik' introduced the concepts of multithreaded layout and parallel CSS. Their prototype browser demonstrated the performance improvements of parallelism.
Adrenaline was a project where an edge server split the web page down into multiple mini pages before sending the results to the Adrenaline browser to render them in parallel.
Zoomm, Qualcomm Research's parallel browser project, focused upon using additional processor cores to prescan the HTML to preload network resources, and process them outside the critical path of page loading. A new approach to CSS matching and styling was also exploited to gain additional speed.
Servo is a parallel browser project from Mozilla which aims to achieve better parallelism, security, and performance. Servo's architecture includes a multithreaded layout engine and GPU based OpenGL rendering.
Flow from Ekioh is a parallel browser primarily aimed at the consumer electronics and embedded systems markets. Flow combines a multithreaded layout engine with OpenGL ES based GPU rendering for improved animation performance and lower memory usage.

Whilst some of these activities have fallen by the wayside, Servo and Flow are actively being developed and enhanced. Although unrelated, they share many similar design philosophies and offer the potential for significant performance benefits.

Will a new rendering engine maintain the wider appeal of HTML?

It's fair to say that Flow is unlikely to challenge Chrome's top spot in the desktop market, but in the more minority use cases, its layout and rendering performance are key to improving the user experience on consumer electronics. By addressing the performance problems of HTML on embedded silicon, Flow helps to ensure that the flexibility of HTML remains a viable option beyond the open web.

Copyright ? 2020 Ekioh Ltd., All rights reserved.
You are receiving this information because you are on our news & posts mailing list. We maintain separate mailing lists for each category of information, enabling you to tailor the information we send you by subscribing or unsubscribing from each category.

Our mailing address is:

Ekioh Ltd.

17B Sturton St

Cambridge, CB1 2SN

United Kingdom

Add us to your address book

Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list.

Email Marketing Powered by Mailchimp

View this email in your browser

Flow Browser Preview on the Raspberry Pi 400

We're very excited to be making a Flow preview available for public download for the first time. Flow has a fast, modern, architecture that doesn't share its layout engine with any other browser. While able to render most websites well, many perfectly, Flow still has some way to go. Each month more pages work, as more JavaScript APIs are added or additional CSS functionality created.

We have chosen to release on just one platform initially, and there are a couple of reasons why. The Raspberry Pi's hardware is largely fixed - you can't swap the CPU or GPU. Variations in hardware and OS setup could cause us to get distracted by issues that really shouldn't be a priority right now.

Secondly, the Raspberry Pi 400 has very similar performance to many set-top box chips, so a release that demonstrates Flow's animation performance on embedded hardware is more useful than on a PC where all browsers can easily get 60fps.

It's been a year since our Google Mail blog post was picked up on Twitter and Hacker News. Our unexpected sudden fame meant we weren't prepared for a public browser release, and expectations were (and probably still are) unrealistically high. Most of the HTML user interfaces that we had tried rendered well, and Flow regularly outperformed other browsers on set-top boxes. But, websites never looked quite right.

Last September, we detailed our work on tracking down and fixing the rendering of various major websites. No one bug was particularly tricky to fix once we had narrowed it down, but the end result made the browser engine feel much more like an actual browser.

In the meantime, some previously working sites have stopped working due to improvements in their content, for instance, Amazon now requires Web Cryptography to log in. This is a feature currently in progress.

This preview has many features missing that you would reasonably expect from a browser. Media source extensions, cryptography, and CSS Grid are being actively worked on. We have plenty more to get on with, including a UI, accessibility, and better text editing functionality.

We generally know which sites work and which don't, but prioritise our commercial customers. Bug fixes that impact them usually fix websites, just not necessarily your favourite website. If you are able to help us track down why a particular website (or library) fails to work, we would be very appreciative of a small test case demonstrating the bug. The more simple the test case is, the more likely we are to fix the bug. We will read all emails but, sadly, may not be able to reply.

And finally, while the preview is for the Raspberry Pi 400, it also works on the Raspberry Pi 4. Previous models use a different GPU with different GPU drivers, so we are holding off releasing for those until we have optimised the graphics support.

We hope this preview demonstrates where we are with a brand new browser engine. The feedback we get for this public preview will directly affect the prospects for desktop platforms. Enjoy it, be critical, but please don't expect Flow to be usable on your favourite websites right now.

For regular updates on our progress, please follow us on Twitter.

To see all our posts please visit our blog page.
For regular updates on our progress, please follow us on Twitter.

Copyright ? 2020 Ekioh Ltd., All rights reserved.
You are receiving this information because you are on our news & posts mailing list. We maintain separate mailing lists for each category of information, enabling you to tailor the information we send you by subscribing or unsubscribing from each category.

Our mailing address is:

Ekioh Ltd.

17B Sturton St

Cambridge, CB1 2SN

United Kingdom

Add us to your address book

Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list.

Email Marketing Powered by Mailchimp

Data Name	Data Type	Options
Name*	Text Box
Email	Text Box
	checklist	Please let us know what type of blogs you are interested in:
	checklist	Select All
	checklist	Product & market blogs

Start Searching Today!

ekioh Sign Up Information

Email Address

Your Address

Post-Registration Data

Validation

Membership Emails

Fixed point vs floating point

Ordering from Amazon using Flow

Can we fix it?

3D Environments in CSS

Design Trends

Flow browser passes the Acid tests

Isn''t it nice when things just... work?

Is the wider appeal of HTML being eroded?

Domination stifles innovation

Moving beyond a single thread

Will a new rendering engine maintain the wider appeal of HTML?

Flow Browser Preview on the Raspberry Pi 400

Comments about ekioh

Recently added URLs

Top 10 Search URLs

Top 10 Categories