Why I Don’t Like Unity

By Jonathan Morton @ November 8th, 2011

Recent versions of Ubuntu use the Unity desktop by default.  The overwhelming consensus on the Internet is that, due to lack of configurability, it is a step back from the Gnome desktop previously used.  I, however, have a very different set of reasons for disliking it, as I will explain here.

I first seriously installed Ubuntu on a netbook as a replacement for Asus’ variant of Xandros.  Then, the Maximus desktop together with a quite usable launcher was the default for the Netbook Remix, and it worked extremely well due to it’s efficient use of screen space – particularly vertically.  However, Ubuntu has moved away from this type of interface since then, and the changes are not for the better.  Indeed there is no longer a Netbook Remix as such, with Unity being forced upon desktop users as well.

Peeve 1: the icons and buttons in Unity are far too big, and there is no obvious setting to make them smaller.  They seem to be made for especially fat-fingered touchscreen users.  I don’t know about you, but my desktop machines and my netbook have ordinary keyboards and mice (or trackpads or trackpoints), so fat-fingering is not an issue – desktop users have been successfully double-clicking on 32×32 icons for over 15 years.  I would much rather see more, smaller icons on my screen so that I don’t have to scroll.  This is a trend which began even before Unity, and considerably impedes navigation on a small-screen netbook.

Peeve 2: the scroll bars are so thin as to be almost impossible to grab, fat fingers or no.  Compare and contrast with the above, and scratch your head.

Peeve 3: the application launcher is clunky and hard to navigate.  I actually have difficulty finding what I want, even though I know what it’s called and where it was in previous versions of Ubuntu.  There is a stark choice between a vapid “favourites” list with a link to the Store, and a massive conglomeration of every single installed application – which isn’t even in alphabetical order.  This is exacerbated by the need to expand the list and scroll down to see all the items in any given category.  I wonder if Unity’s designers have ever heard of “discoverability”?

Peeve 4: there is no screensaver support.  Yes, I know screens technically don’t “burn in” any more, but I want to see something pretty when the screen is locked or blanked.  The settings for screensavers have simply disappeared.

Peeve 5: Unity is bloated.  This surprised me greatly, considering how simple it appears on the surface.  Yet when I installed Ubuntu on a salvaged Thinkpad A20p, I found that it would swap itself to death at the slightest provocation.  With a 700MHz P3 and 256MB RAM, the specs are not much below a netbook or an ARM-based tablet – and perfectly representative of an old machine that might be scrounged up for a child, an elderly relative or a disadvantaged family, for which Linux is supposed to be ideal.

A quick look in ‘top’ showed the culprit.  Such stalwarts as xchat and gnome-terminal were content in a few megabytes of resident memory, and even X11 seemed to be surviving on 20MB.  Firefox, predictably, was consuming rather more, apparently competing on even terms with unity-2d-panel and some Python script which was updating the package database cache.  Even though the Unity dock was hidden, the unity-2d-panel was keeping tens of megabytes alive enough to remain in RSS, and this quantity only increased after I convinced Firefox to quit.

Now, a script which walks over a database to create a cache can legitimately consume a lot of memory, so long as it does it’s job and then gets out of the way.  But I am completely at a loss to explain why managing a simple dock (which was hidden at the time due to the full-screen terminal) and a menu bar with a few widgets in it – which are less functional than the Gnome equivalents – can keep a 40MB working set active (not even including X11).  This does not bode at all well for Ubuntu’s aspirations to use Unity on tablets, a task for which it was obviously otherwise intended.

As for the Thinkpad, I think I will try switching it to xubuntu and see if that successfully removes Unity from the equation.  Wish me luck.

How can I make my ARM device fast?

By Jonathan Morton @ March 2nd, 2011

In a previous article, I described common performance pitfalls that ARM devices typically succumb to.  Here, I will lay out how to avoid most of those problems.

Tip 1: Give your designers representative hardware to test on.

The latest ARM hardware has roughly the same performance as a good netbook.  So give your UI designers netbooks or nettops (based on Atom, ION or AMD Fusion), if not as their main workstation, then as a performance-appropriate test platform.  They aren’t very expensive and won’t take up much desk space, and can usually be multiplexed into their existing keyboard, mouse and monitor.

This will encourage them to write efficient software in the first place, so do this as soon as possible when setting up the project.

Even better is to give them the real hardware to try out, but a netbook has the advantage of being usable in a desktop-like way, so it can be used for debugging.

Tip 2: Understand, before specifying hardware, what you need it to do.

Do you want simple 2D graphics?  Video?  Alpha blending (and is it premultiplied or not)?  Alpha blending on top of video (which probably requires “textured video”)?  3D?  Two-way video?  High definition?  Dual displays?  Touch gestures – with or without stylus?  ClearType?  More than one of these simultaneously? Read the rest of this entry »

Why is my ARM device slow?

By Jonathan Morton @ March 2nd, 2011

At Movial, we are often asked to help customers achieve their dream user interface and multimedia experience with some selected hardware and/or software platform. Usually we are happy to provide our expertise, but all too often those of us at the coalface issue a collective groan when we are told what is expected of us.

The task often proves difficult due to mismatches between the hardware’s capabilities or design, the software toolkit, and the expectations of what can be achieved with them. This article will explain some of the difficulties we encounter and how customers and managers – that’s you – can help to maximise the likelihood of success.

The first and most important thing to remember is that embedded or mobile devices do not have the same capabilities as the PCs that you may be used to on your desk or at home.

Typical PCs have enormously powerful CPUs and graphics processors, linked by high-bandwidth buses, and can therefore get away with a lot of brute-force-and-ignorance in the software department. This ability comes at the cost of extremely high power consumption, which can easily reach into the hundreds of watts.

But this is unacceptable in the mobile domain, where a pocket-sized battery is often required to last for days. Hardware manufacturers therefore work hard to produce highly efficient processors inside a one-watt power envelope. The latest OMAP4 and Tegra2 chips are roughly as fast as a good netbook. Obviously, older chips – which may be cheaper – will have even less performance.

This all means that for a good user experience, the available hardware must be used to maximum efficiency, and special features of the hardware must match up to what is required. When this is not the case, your device will be slow. Read the rest of this entry »

Flash Storage Devices (and how slow they are)

By Jonathan Morton @ February 21st, 2011

There’s been a lot of press in the past year or two about SSDs, and how they are revolutionising hard disk performance for servers, laptops and desktops (at a price).  In the embedded world, however, we’re pretty much stuck with SDHC cards and USB thumb drives, which are both built down to a price rather than up to a benchmark.  After being bitten by ludicrously long write-a-rootfs times once too often, I thought I’d investigate the problem in detail.

The source of the problem is that SDHC cards and USB thumb drives are both designed to be as cheap as possible, while still offering good performance for typical FAT16 or FAT32 implementations when writing “large” files – ie. photos at 1MB each or videos at somewhere above that.  But when developing for Linux, we don’t use FAT, we use ext2 or ext3 (or, when we can get it, ext4).  These have very different layout and access patterns than FAT.  FAT puts all it’s metadata together at the start of the disk, and then writes files in (usually) 32KB aligned clusters, and in a typical camera implementation these are expected to be contiguous.  Ext2 (from which ext3 and ext4 are very closely derived) puts metadata in groups spread across the disk, close to the data – which means that a large file will be broken up periodically by the gaps for the metadata, and then the metadata itself is broken up into small pieces.  Furthermore, it turns out that the default allocation algoritm for ext2 leaves small gaps between files – ext4 improves this greatly.

SSDs can cope with ext2’s idiosyncracies, because they are also designed to cope with NTFS and Windows’ foibles, and manufacturers have the budget to do so.  (Windows, or at least XP, is extremely bad at keeping files contiguous under normal desktop use.)  Basic SDHC and thunb drives, though, do not.  Ext2’s access pattern heavily exercises mechanisms which, in these cheaper devices, are designed to cope with corner cases rather than daily use. Read the rest of this entry »

Baby steps towards RandR goodies for xf86-video-omapfb

By zuh @ November 9th, 2010

For a long while I’ve been wanting to implement RandR support for xf86-video-omapfb, but never really got around it. Fortunately, Movial came to the rescue and allowed me to kickstart the RandR code on work time, yay for Movial!

The main question (which is always ‘why’) can be answered with the planned feature list and their use-cases:

  • Display mode switching: “real” and pixel doubling (scaled) modes
  • Rotation: orientation response to accelerometer data for example
  • Screen migration (cloning): HDMI output in your device? Flick of a switch and you are on it.
  • Screen expanding: Merge multiple screens into one. This one is a bit iffy, current kernel drivers don’t seem to support it, but…

The ‘how’ is too large topic for this post, but the general idea is to take advantage of the API the revised omapfb kernel driver (big thanks to Tomi Valkeinen) offers and manipulate the OMAP overlays to scan the framebuffer to different outputs.

I will post updates when the support reaches milestones, but here’s a “teaser” (ogg/theora, 860KiB, on youtube too) showing a Blaze board obey a script that enables/disables the different displays in a sequence with the xrandr tool. Blaze has two LCD’s, HDMI port and even an integrated DLP Pico projector though sadly I couldn’t get that one to work for the demonstration.

The current code is available from the git repository, master branch. As usual, testing and patches are welcomed (though don’t expect much from the testing part just yet).

Final release of the ARM Linux Internet Platform

By Adrian Bunk @ September 13th, 2010

ARM and Movial released the fifth and final release of the ARM Linux Internet Platform. The biggest changes are:

  • Totem media player added
  • HAL removed
  • Xorg server 1.9

The full list of chagnes is here.

This is the final release of the ARM Linux Internet Platform. For new development please have a look at Linaro.

Browser D-Bus Bridge 1.2

By zuh @ September 10th, 2010

Another bugfix release of BDB was more than overdue, finally got around to do it.

There is on sort of new feature included though, the build supports now building the WebKit flavor against (a modified) QtWebKit. The actual jscorebus code is unchanged wrt this, it just gets linked to a different library. This is necessary since JavaScriptCore is (at least currently) not distributed as a separate library, but instead inside the WebKit libraries.

Unfortunately QtWebKit doesn’t expose the JavaScriptCore API (I think they want to leverage QtScript usage by this) so there are few patches to QtWebKit required to actually use jscorebus with QtWebKit. The patches are included in the (very general) setup instructions.

Changelog for 1.2 can be viewed here.

Matrix 1.4

By Adrian Bunk @ September 6th, 2010

We’ve just released version 1.4 of the Matrix tool. It contains various smaller changes and enhanchments, the most important one being that with -f the (often slow) check for dirty files is no longer performed. Check the log for details.

Sources are available as tarballs and from git.

Browser D-Bus Bridge 1.1

By zuh @ August 31st, 2009

Since the bug fixes were starting to pile up (thanks to all that contributed patches!), I decided to make a bugfix release of BDB.

The changelog is not that impressive (no new features), but since the bug fixes include fixes for crashers, it’s definitely worth to upgrade to 1.1.

Pixman gets NEON support

By Jonathan Morton @ June 12th, 2009

I’ve been working on NEON fastpaths for Pixman lately, and as I write, these are being pushed upstream, hopefully in time for Pixman’s next stable release.  They complement some work already done in this area by engineers at ARM.  Some ARM hardware does use 32-bit framebuffers, but hardware constraints still seem tight enough that 16-bit framebuffers are still common.  So while the ARM guys focused mostly on 32-bit framebuffers and some internal operations, we focused firmly on 16-bit framebuffers.

For those who don’t know, Pixman is a backend library shared by Cairo and X.org, which takes care of various basic 2D graphics operations when there isn’t any specific GPU support for them.  It gets pretty heavy use if you use the XRender protocol on a bare framebuffer, for example.  So optimising Pixman for the latest ARM developments will make Gecko faster, as well as any of those “fancy” compositing window managers which are all the rage these days.

Now the following operations are accelerated, all on RGB565 framebuffers (which may or may not be cached):

  • Flat rectangular fills.  (These also work on other framebuffer formats.)
  • Copying 16-bit images around.
  • Converting 24-bit xRGB images (eg. a decoded JPEG) into the framebuffer format.
  • Flat translucent rectangles.
  • Compositing 32-bit ARGB images (eg. a decoded PNG).
  • Glyphs and strings thereof (8-bit alpha masks, with an overall colour that might be translucent).

Most of the listed operations are now at least twice as fast as they were without NEON, and many come within spitting distance of available memory bandwidth on typical ARMv7 hardware.  Using a benchmark of common operations (as issued by a common Web browser visiting a popular news portal), we measured an overall doubling in performance, despite the most common drawing operations being extremely tiny and therefore difficult to optimise.

In some cases on a more synthetic benchmark, the throughput is vastly greater than that, at least when running on an uncached framebuffer (which tends to hurt generic code very badly).  The main performance techniques were to read from the framebuffer in big chunks (where required), preload source data into the cache, and then process data in decent-sized chunks per loop iteration.  This essentially removes the performance advantage of a “shadowed framebuffer”, so you can now sensibly save memory by turning it off.

We also found some opportunities for reducing per-request overhead in both Pixman and X.org.  Hopefully these improvements will also be integrated upstream in the near future.