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.

Support CNX Software! Donate via PayPal or cryptocurrencies, become a Patron on Patreon, or buy review samples

Subscribe
Notify of
guest
19 Comments
oldest
newest
Anonymouse
Anonymouse
1 month ago

No uBlock origin = no usable browser

Gediz
1 month ago

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.

ade
ade
1 month ago

Maybe something like https://pi-hole.net/ can be used together with this browser as an alternative to ublock ?

Anonymouse
Anonymouse
1 month ago

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”….

Adrian
Adrian
1 month ago

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

Adrian
Adrian
1 month ago

I was wrong – AI ad blocking is already a thing – one of the interesting examples:
https://www.usenix.org/conference/atc20/presentation/din
https://github.com/dxaen/percival

Stilman
Stilman
1 month ago

OMG, cancel culture has hit cnx-software

nobitakun
nobitakun
1 month ago

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.

Theguyuk
Theguyuk
1 month ago

If it is such a all rounder SBC, why does it a specialist browser ?

Theguyuk
Theguyuk
1 month ago

Need

Milkboy
Milkboy
1 month ago

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?

Dan C
Dan C
1 month ago

How is Apples x86 CPU emulation relevant when chromium on Pi is already a native app?

Milkboy007
Milkboy007
1 month ago

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.

DurandA
DurandA
1 month ago

Did anyone try the Servo browser on the Raspberry Pi? How does it perform?

willy
willy
1 month ago

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… Read more »

Theguyuk
Theguyuk
1 month ago

We have more running video in page garbage these days and adverts etc.

Milkboy
Milkboy
1 month ago

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.

dgp
dgp
1 month ago

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.

Tof
Tof
1 month ago

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

Advertisements