Fiber Update

It’s been a while since I’ve posted about Fiber, so here’s a brief update.

Sidebar tabs

I’ve read quite a bit about what people really want to see in a browser and I’ve repeatedly heard about the disappointment of my tab sidebar decision.

At first I dismissed it because I hadn’t really heard of it before, nonetheless know that it’s a beloved feature for many. I also wasn’t keen on the idea because all the tab form-factors were a horizontal strip and I wanted to (lazily) deal with one orientation.

The original plan was to allow an extension to handle the more crazy form-factors, but as I was blueprinting the APIs on paper I quickly found the tab-bar becoming a nightmarish monster which would have made custom tab extensions painful. Ultimately as a shortcut until a nice API can be made (and many more critical APIs can be rolled out) I’ll be adding sidebar tabs as a native feature. I may look at some sort of button form-factor as well, such as the ones commonly seen in mobile browsers.

(We announced flippin’ Plasma Mobile, no KDE developer doesn’t have phone on the brain!)

With this development though, I’m going to put tab extensions onto the backburner. I’m not completely satisfied with hardcoding something potentially invasive, but in these early stages battles much be picked, and there are other features the tab-bar can gain from that decision.

Performance and Rendering Engines

Before I get into some performance stuff I have on tap, there’s an elephant I’d like to address.

I’ve heard a lot of complaints that WebEngine/Blink/Webkit are “bloated” and resource intensive, and that this selection would inevitably make Fiber a resource-hog browser “like Chrome”. I’ve also heard that Fedora isn’t shipping WebEngine, leaving users out in the cold.

On Fedora not shipping WebEngine… I can’t say much for that. Programs will start using it, and it’s going to be an increasing problem for them the longer they hold out. I won’t switch to Gecko, nor will I be providing some sort of “-engine” build switch for Fedora or other holdouts; it’s not a practical validation for the time or complexity required to support that, and it would certainly introduce more issues into the browser itself than it would solve for any issues Fedora finds in the engine.

On resource usage it needs to be pointed out that Webkit/Engine/Blink itself is not particularly heavy, and some browsers (like Epiphany) use it and got top marks in simple resource usage tests. Even if the results weren’t 100% accurate, the data was still compelling. Ultimately the rendering engine is only one factor of resource usage, and other factors will be at play.

That being said I’m not concerned about bean-counting megabytes, as I’m not out to make a lightweight browser. I’ll try to be efficient of course, but Fiber has some much steeper hills it must climb to maintain speed and resource usage for one reason; extensions. Extensions are inherently less efficient than native code, and many times when complaints Firefox or Chrome performance arise it can be traced back to misbehaving add-ons. With Chrome the browser separates extensions, plugins, and rendering engines into processes which is heavy – but stable. If Fiber did the same it would quickly become much heavier than Chrome as by design it will have multitudes more extensions.

Put simply if people start complaining when they have 3 or 4 inefficient extensions gumming up the works, imagine the moment of panic when you consider a browser that will ship with over a dozen default extensions for basic browsing!

Which brings me to the juicy performance stuff;

Simple by default; Fiber ‘Performance Tuning’

You often see guides suggesting how to “tweak” Firefox or Chrome to be faster. Often they’ll recommend isolating bad extensions and altering the basic behaviours of how the browser operates. Often though the defaults have been carefully considered… It’s not like Firefox is shipping the “second best” configuration they can think of.

With that in mind computers are extremely diverse and for all intents and purposes no two computers are alike; OS, RAM, CPU, connection, physical location, and even drivers affect how well a computer can perform. For Fiber and it’s extension-happy orientation performance can quickly become a nightmarish prospect; how can we guarantee that a browser with dozens of potentially unoptimised ECMA-driven plugins will perform well? And, if the user must intervene and “tweak” the system, how can we make this process simple and efficient?

The solution being implemented is to boil tweaking down to simple but powerful sliders the user can adjust: “Extension Processes” and “Loading & Fetching”.

fibershotThese sliders are the first two added for performance tuning, and more may be added if they make sense. These sliders aren’t completely voodoo though, and simply act as a front-end to the more fine-grain options hidden in the Configuration utility, and will adjust those values in a way that is safe and sane. “Simple by default, Powerful when needed”.

Extension Processes

Though not anywhere near fleshed out, this had to be added early to ensure the concept would be propagated throughout the extension architecture. Extensions in Fiber will have a “separateProcess” variable in the manifest file which can hint how the browser should manipulate its process system. Depending on how the user has set the “Extension Processes” tuner, the two values together will affect how extensions will be processed in Fiber.

When set to “Fewer Processes” only extensions which specifically request process separation will be split from the main process. When set to “Most Processes” all extensions will be placed into separate processes regardless of setting. The middle-road option will favour process separation, but not force it.

The idea behind this is to let simple extensions like bookmarks managers be in the main browser, while more complex extensions like download utilities can safely ensure they won’t poison the main process.The only catch-22 may be processes which embed more dynamic widgets onto the UI; I’ll be trying to make stock widgets accommodating, but if embedding widgets onto the interface it may force an extension doing so onto the main thread. I don’t know fully yet whether this will be the case.

Loading & Fetching

Loading and Fetching will affect how eager the browser is to load unopened tabs, and how willing it will be to forget inactive tabs. “Fewest Resources” will lazy-load everything, while being more eager to dump data. “Eager Loading” will actively load unopened tabs, and keep everything in memory.

Work Status

I took a break to nail down some VDG work, so progress had briefly slowed during that time to pencil-and-paper work. This was prompted by me merging some Fiber-related icons into Breeze, and then going on a binge where I frothed at the mouth and made 47 application icons. DON’T JUDGE ME. Now that I’m just waiting to make some adjustments to some straggling icons, Fiber development is back on full-tilt – at least the full-tilt that a full-time employee can give in his off-hours.

Much like Firefox, Fiber uses Sqlite for profile storage. Earlier today marked a milestone where Fiber is now creating empty profiles with config tables, loading them with data, and providing nice clean functions to reliably read that data.  Profiles themselves have solidified quite a bit, and now the relationship between all the moving parts is much more clear.

Work is now going into making profiles able to validate and repair themselves, adding “isValid” checks before attempts are made to use a profile, and getting proper but meaningful alerts in for serious issues.

The profile manager has shaped up nicely, and expanded a little bit beyond my original scope. There’s still a ways to go before the profile manager is 100% complete, but even to a relatively green Qt developer the quality of the toolkit has made things easy.

The Fiber icon has also been tweaked, and now has multilple resolutions which are pixel-perfect.


14 thoughts on “Fiber Update

  1. I loved the simplicity of rekonq but have been using Firefox since it is now is showing the lack of love. I badly want all the amazing integrations with my Plasma environment I’ve come to use everyday. Firefox just doesn’t bridge that gap for me. Is there source up somewhere yet? So we can play with it or just try it out. Maybe I missed it?


    1. Nope, you didn’t miss anything.
      Fiber is still quite some time away from a usable release, and it’s a little while off before I’ll be opening up the source to other developers. My personal milestone will be when I get to the “hello world” extension; at that point everything will be opened up to other developers.


  2. Hi,
    first of all, thanks for the great project and the great ideas and concepts. As a former casual rekonq contributor, I very much appreciate your work! 🙂
    But your post raised one concern: Did I understand you correctly, that you plan to write only the small core in C++ and have all the extensions QML+Javascript only?
    If so, I can only give you an advice, not to do so. At KDAB we had several clients, who tried to do big applications with logic implemented in QML+JS. They come to us in order to ask, why their application is that slow. It’s always the same story: QML is really nice for UIs and JavaScript is its best friend and invaluable for all those small tasks, that have to be done in a nice UI. But it is not there for big tasks. It’s just not optimized for that and will always be too slow. One of the big advantages of QML over their competition is how easy it is to integrate C++ and QML to gain the desired speed. We should take advantage of that! 🙂


    1. Thank you for the advice!

      So, yes and no on the minimal core. While “everything will be an extension” in Fiber, it doesn’t mean “everything will be QML/JS”.

      The main browser chrome will be done in native QWidgets, and extensions will mostly define widgets via a manifest file, meaning the main UI won’t be scripted. This means that the user can configure their UI without requiring the extensions be running, and we don’t need to worry about scripted behaviours being naughty and messing with the main UI. Extensions could certainly alter an existing button it specified via an API (such reporting a progress value, changing the icon, etc) but they cannot programatically create or delete buttons. Additionally, it allows the script connected to the button to run in a separate process, as the Fiber API would handle the IPC.

      I do have a provision to embed QML-driven widgets onto the UI, but with the increasing number of complexities and ‘gotchas’ I’m not entirely sure if they will make the cut; and I’d much rather make a richer API that could eventually be made DWD-compatible than get lazy and let a problematic API run amok.

      Core features including the Multitool, main menu, tabs, status overlay, context menus, and a few other fiddlybits will be native. These tools will interact with extensions but will not be directly driven by javascript or put in a position where they may be blocked waiting for a script to execute.

      QML/HTML will mainly be used when extensions want to present popouts or pages. For example, the bookmarks popout in the design images would totally be QML, as would a “new tab” page. For glue and logic there’s Javascript; but Javascript will not be put in computationally intensive positions for common operations, and it won’t drive the interaction points.

      Fiber will have a thoughtful API that will use a combination of native tools, JSON, JS, and QML deployed in a way that should give the browser a good balance of speed, flexibility, and power. Where it makes sense it will use JS and QML will have their appropriate places, but it won’t use them everywhere for the sake of being trendy.


  3. A couple of things –

    First, with “sidebar tabs,” please also consider _hierarchical_ tabs – I can’t use Chrome’s sidebar tabs at all, because I depend on hierarchy for organization. In addition, hierarchy can be useful even in “classic” horizontal tabs – Firefox added Tab Groups, after all.

    Second, I’d suggest putting serious thought into using CEF, the [Chromium Embedded Framework]( It’s a clean modularization of the Chromium Content API, and also could provide for future migration – the Servo project is implementing its engine to be 100% compatible with CEF, so that it can be swapped in without any code changes in the host program.

    Definitely looking forward to more Fiber, though – it’s certainly got my interest!


    1. This is a very, very interesting find! I’ll be researching this further, thank you for the link.

      Edit: “tab grouping” is on my radar, though I’m still looking into how it should be executed. I’m not sure yet how it will be implemented as I have a few behaviours along with a few visual designs on paper. This would give both horizontal and vertical tabs a virtual two-level hierarchy. Horizontally this would be represented as an accordion structure similar to my first mockups. Vertically we have more room, so I’m looking at other approaches, but whatever approach is taken will probably err on the simple side.


      1. Hm, I’m really not sure why it should be limited to two levels – it may help if I explain my use case a bit further.

        At the present time, in Firefox, I have 2,716 tabs. Near the “top” of the tab sidebar, they’re a bit compulsively organized – one subtree for “Code”, one subtree for “Fiction”, one subtree for “Games”.

        To drill down further, the “Games” section has subtrees for my D&D games, browser games I’m playing, Dwarf Fortress, SLASH’EM, etc.

        In each of those subtrees – like Dwarf Fortress – are tabs related to that. One subtree for the DF Forums, another for the wiki, etc.

        If I open links from a forum thread, the forum thread is the root of a subtree containing _those_, and this structure continues.

        That’s it for the organized top area.

        The further down one goes (vertically) in the sidebar, the less organized they become, until it becomes basically chronological and flat. Once a month, I go through the unstructured section, prune out things I won’t be returning to at all, transfer things I won’t be returning to soon – or will only use as a reference if needed – to bookmarks, and organize the remainder up top.

        In order to find the things I need, I use a mixture organization and the Firefox address bar’s “switch to tab” capabilities. The former for the structured section, and the latter for the unstructured. Since the unstructured tabs are “recent”, I can generally recall enough of the title or URL to search for it from the address bar.


        1. Wait… Are you talking bookmarks, or tabs? Like, tabs trying to run?

          How is your everything not on fire right now? O_o;;;

          I think I might be confused about how your browsing habits… Work…


          1. No, those are definitely tabs. The thing is that Firefox can lazily load tabs when you visit, so they’re not really consuming much of anything in the way of resources until you do.

            I have 8gb of ram; on startup Firefox uses about 3; that gradually grows to 6 or so before memory pressure means I need to restart it – but that takes a couple weeks to get to, in general.

            Really, the only two bottlenecks for me are that:

            1.) Automatic session saving from Session Manager really thrashes the disk I/O since this is a laptop with a spinning rust drive, and that happens in the main process so it blocks the UI
            2.) Startup takes ~10min


            1. By the sounds of it, tabs aren’t really the ideal way to be managing your browsing. It sounds more like you should be using bookmarks, especially given your description. Your browser just isn’t meant to be running that many tabs at once; it’s not the design of tabs.

              Generally, the idea for tabs is that they’re what you’re doing at that moment; they’re the volatile organisation of your browser. If I’m programming I’ll have 5 or 6 tabs open for development while I back-reference materials – and I’ll close them when I’m done. If I think I’ll need them later, I’ll just bookmark them. Ctrl+D, Enter.

              At most if I’ve been highly active in a day, I’ll have 30 tabs open, and usually at that point I have 20 tabs I can close without hesitation. 7 or so seems to be my average. When I read web-comics I’ll use Firefox’s “Open all in tabs” tool to open 10-15 comics – I do the same with news sites, both of which are closed in rapid succession. Tabs just aren’t meant to be around for that long, nonetheless be organised into sub-trees.

              In Fiber, I can’t say I’m going to be designing to accommodate your use-case; I would much more highly recommend using bookmarks and app tabs. App-tabs when you want the page running in the background or consistently loaded, and bookmarks when you just constantly refer to a page. Otherwise, at least until the tabs API comes online (now delayed) and someone makes a more in-depth tab organiser, I can’t really say Fiber will offer that workflow.


            2. What you need is an extension that would automatically create bookmarks for all websites you visit (updating the same bookmark when you navigate inside one tab, etc.). That would allow just the same kind of organization you want, but without the drawbacks you currently have.
              This is something that would obviously be simple to do in Fiber, right?


              1. I doubt it’s a feature I’d implement personally, but it should definitely be doable. It or something similar should be possible in other browsers (at least Firefox)


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s