Flow Browser, a Raspberry Pi optimized web browser for HMI

Most people will use Chromium on Raspberry Pi boards simply because it’s now the default browser in Raspberry Pi OS. But the performance may not be optimal, and UK-based Ekioh has developed the Flow Browser optimized for performance on Raspberry Pi with multi-thread support and 3D accelerated graphics.

There’s a caveat though, as the Flow Browser has been developed from the ground up, i.e. not based on Webkit or Mozilla Engine, with human-machine interfaces (HMI) in mind, rather than individuals browsing the web, and that means that while performance will be better, site compatibility does suffer at this point in time.

Flow Browser Raspberry Pi Optimized web browser
CNX Software rendered in Flow Browser running on Raspberry Pi 400

Key features in Flow Browser

Before going into benchmarks and other tests, let’s check some of the key features listed for Flow Browser:

  • HTML & CSS3CSS – Animations and Transitions, CSS Transforms (2D and 3D), CSS Flexbox, Bi-directional text layout
  • Graphics – Web Fonts – Canvas, SVG & WebGL
  • Media – HTML5 Audio & Video tags
  • Scripting and Storage – ECMAScript with JIT (SpiderMonkey), Web Storage, and Web SQL
  • Web Workers & Web Sockets – NPAPI plugin support
  • Platforms
    • Works with Linux, Android, Windows, and other OSs
    • Integration into STB vendors’ APIs and OpenGL ES
    • SDKs with example ports
    • Sample GStreamer integration for Media APIs
  • Resource Requirements – Smooth animations from a GPU-enabled processor with just 1K DIMPS
  • Content Development
    • Inbuilt content analysis and debug tools
    • Linux, macOS and Android desktop builds for off-target content development
  • Regular Updates – Improving site compatibility and feature set

So it’s not exclusively for Raspberry Pi but also other embedded platforms with a web-based graphical interface such as set-top boxes, controller and others.

Benchmarks and site compatibility

We asked the company to run some tests and benchmarks for us. First starting with html5test.com score being 332 points for Flow compared to Chromium’s 471 on the Raspberry Pi 400. Ekioh explained that some of the features of a standard web browser may not be needed for HMI use cases.  It’s not too bad as sites like the Guardian, Wikipedia, Twitter, The Register can apparently render just fine, and so is CNX Software.

All benchmarks below were run on a Raspberry Pi 400 keyboard PC connected to HDMI monitor set to 1920×1080 resolution and the browser window set to full screen, and browsers using default settings:

  • MotionMark 1.1  – Overall test of different graphics techniques that uses some random pattern generation so test results can fluctuate.  Average of 3 runs (larger is faster):
    • Chromium – 6.24, 8.04, 7.13: Average = 7.14
    • Flow – 11.83, 11.70, 12.27: Average = 11.93
  • Particle Acceleration – Heavy graphics animation
    • Chromium – 15 fps
    • Flow – 26 fps
  • Sinz Maze
    • Chromium – 80.25 tiles per second
    • Flow – 127.16 tiles per second
  • CraftyMind GUIMark HTML4 Test – Heavy use of layout (needed to average the running score by eye as the benchmark’s test button is broken)
    • Chromium ~ 25 fps
    • Flow ~ 58 fps
  • JetStream 1.1 – Pure JavaScript test,  in effect, comparing Mozilla SpiderMonkey JS Engine used in Flow with Chromium’s V8 Engine.
    • Chromium – 49.912
    • Flow – 51.295
  • UI Layers – Ekioh’s own layout benchmark that varies the amounts of text being laid out to converge on 30 frames per second, higher scores are better.
    • Chromium – 4
    • Flow – 22

All benchmarks are graphics-intensive to show Flow’s edge, except for JetStream which shows similar results compared to Chromium. So Flow really shines in the rendering of text and 3D graphics, which makes sense since it’s optimized for HMI. I did ask for SpeedoMeter 2.0, but results were not provided.

The company told CNX Software that the main differences between Flow and other browsers are multithreaded layout and GPU rendering:

  • The former is what makes Flow so much faster in the CraftyMind and UI Layers benchmarks which are layout dominated. On the Pi’s quad-core processor, Flow is able to layout 4 times as much text as a Chromium which has single-threaded layout.

  • The latter (GPU rendering) accounts for Flow’s increased performance on the Particle Acceleration, Sinz Maze and MotionMark benchmarks.

Trying out the Flow Browser

Please note that the Flow Browser is not an open-source project, but you can try it for free on Raspberry Pi as Ekioh has just released a preview image with the Flow Browser based on Raspberry Pi OS.  It’s free for personal use, but you can not use it for any commercial purpose unless you obtain a commercial license from the company.

You may be able to find additional information on the product page.

Share this:
FacebookTwitterHacker NewsSlashdotRedditLinkedInPinterestFlipboardMeWeLineEmailShare

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

ROCK Pi 4C Plus

20 Replies to “Flow Browser, a Raspberry Pi optimized web browser for HMI”

    1. I agree with you but I think key point with this tool is the following passage
      >rather than individuals browsing the web

      Target websites will be most likely already known sources provided by developers.
      Also, it would take a lot of effort to make a browser which is developed from the grounds up to be uBlock Origin compatible.

      1. Pi hole and other DNS based blocking are no alternative to ublock as it lacks most of the blocking capabilities. As advertisers moving forward to cname cloaking and delivering their trash on the same domain DNS based blocking will sooner or later become totally obsolete.

        Only use case for such a stuff was to block a minimum on devices you have no full control granted by the manufacture. This was(?) for example the cases with iOS devices and the forced safari “experience”….

        1. A middle path would be using an ad blocking proxy like the good old Proxomitron.
          Unfortunately in our post web2.0 world where everything is javascript based and the DOM is built dinamically even that is not working too well anymore.
          So indeed for the moment the best solution is an “in-browser” plugin like uBlock which can access the DOM.. but even that is at the mercy of the provided browser APIs.
          Let’s see what the future will bring but I’m surprised that there are no tools yet trying to leverage AI for ad blocking :))

    2. Nope, what is needed is a centralized service that is built in in open source browsers that block ads by default, in the same way ublock does, and shit to chrome with their google ads everywhere and slow browser. Installing an ad blocker in 2021 is kinda ancient, a basic feature which needs to be native in a browser, like hardware acceleration. If you later don’t want it, ok, disable it.

      1. Why does Apple M1 SOC need native app if it has rosseta?
        Why do we need tools for anything when our fingers is all rounder?
        Why indeed?

          1. i think you are missing my point.
            Optimized apps are preferable.
            Emails clients are a better analogy. just because general webmail is available, doesn’t mean that email clients aren’t needed.

  1. It’s refreshing to see a new browser come here to remind the established ones that they deliberately sat down on performance for many years. They’ve been cheating by delivering cached contents before the page loads and such tricks, but when it comes to rendering a page, it takes longer nowadays to display an average web page on a quad-core i7 than it used to 15 years ago on a 1.5 GHz pentium-M with 512MB of RAM. We do pay for the CPU and RAM we have in our devices, they’re not there as a tax to help developers’ laziness. And each (rare) important improvement that appeared in the past in this area was the result of a new participant entering the game and shaking the house. Let’s hope some code will be cleaned up to make existing browsers look better in comparison to this new one.

      1. Yeah. 15 years ago we only need a pop up blocker for ads, no tens of tabs opened at the same time, site still able to load on dial up / 256K DSL, Coffe for youtube buffering are great, etc….

        Me 15 years ago: what is browser tab? do you mean addon toolbars?

        Back then website is mostly is 70:30 actual-content to gabage ratio.
        Nowadays its flipped 30:70, and some clickbait site is like 90% ads.

    1. I remember browsing sites on a 25mhz 68040.. I wouldn’t go back to those times and I appreciate how much better web design has gotten. But I would like to send a terminator back in time to just after html5 pushed flash out and before this stupid “modern” scrolling style came in to change how things turned out.

  2. “not based on Webkit or Mozilla Engine …that means that while performance will be better, site compatibility does suffer at this point in time.”

    We are currently replicating the old era of “this website is optimized for Internet Explorer”, just replacing Internet Explorer by Webkit/Chrome.

Leave a Reply

Your email address will not be published. Required fields are marked *

Khadas VIM4 SBC
Khadas VIM4 SBC