Archive for the ‘Linux’ Category

Why I Don’t Like Unity

Tuesday, 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?

Wednesday, 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? (more…)

Why is my ARM device slow?

Wednesday, 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. (more…)

Flash Storage Devices (and how slow they are)

Monday, 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. (more…)

Browser D-Bus Bridge 1.1

Monday, 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

Friday, 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.

Maemo5: SGX vs. pixman

Tuesday, March 24th, 2009

I finally found the time to check out Maemo5 alpha on Beagle board. I was mainly interested in the X.Org hardware acceleration as they have implemented EXA acceleration API using the PVR2D library for SGX. SGX is the 3D GPU from Imagination Technologies used in the OMAP3 CPU.

I followed the instructions and got it up’n’running in no time encountering nothing undocumented.

Some debug prints from the X.Org output:

PVR2D SGX EXA acceleration initialized
DRI2 initialized

I started with cairoperf and ran it using xf86-video-omapfb driver (no EXA) and then with Nokia’s EXA accelerated fbdev (yeah, they are using the old name).

The results were surprising: 13 relatively small speed ups and 585 relatively big slowdowns.

I also tested with mx11mark and the results were in line with cairoperf results: total score with x-v-o was 17 and with Nokia’s driver only 13.

I wouldn’t mind if somebody proved my tests wrong…

Android on Zoom

Thursday, October 30th, 2008

I had never touch Android before but it took only a day to get it running on a Zoom board. I think getting a new complete Linux setup running on a real device could be much harder although there were some bumbs on the way.

I mainly followed the instructions on the omapzoom.org and on elinux.org. The JDK from my Debian Etch didn’t seem to work, so I had to download the JDK from sun.com and set up some environment variables. Once those were set the compilation succeeded without problems. I would have saved some hours if I had read the instructions properly in the first place.

The instructions were a bit vague on to do after the compilation was finished. Eventually I created the card.img that acts as a MMC/SD card and launched the emulator:


./out/host/linux-x86/bin/emulator -sdcard card.img -system out/target/product/ldp1/ -kernel ./prebuilt/android-arm/kernel/kernel-qemu

The emulator runs the real ARM root file system image with qemu so it fully matches the actual file system. The file system includes e.g. ssh so I could IRC with the terminal application but it doesn’t include e.g. cp, which seems a bit odd. The file system directory hierarchy looks completely weird and messy to me. It mounts a read only ramdisk as root and data, system and sdcard under it.

Android provides Android Debug Bridge (adb) that is capable of sending files to the root file system run by the emulator or giving you a remote shell, among other things. I used it to get more complete busybox there and tarred (no compression) the /data and /system directories to the fake MMC/SD card. If I had had a Linux setup that understands YAFFS file systems this would have been a bit easier since I could have used the original images directly without copying the content from the running emulator.

I set up an EXT3 root file system to a real SD card from the ramdisk, system and data tar balls and replaced the init.rc with init.omapldpboard.rc and booted the Zoom board with the uImage built separately according to the instructions.

The desktop (or home) is something new but the menus that open from the bottom actually seem quite traditional. The UI looks quite polished and is very responsive on the Zoom. Everything feels snappier than I would have expected. The Zoom doesn’t have WLAN and I didn’t find anything to set up the wired network with a quick search so I didn’t have a network connection.

I’m sure we’ll see interesting devices (in addition to G1) based on Android in the future.