1st time running onboard with default theme is painfully slow

Bug #1070760 reported by Alex Chiang on 2012-10-24
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Scott Sweeny
cairo (Ubuntu)

Bug Description

The current behavior tweak of onboard is to hide it when the session starts.

This leads to a useability issue when starting the dash for the first time, e.g. as the dash opens and an empty onboard frame is rendered but not usable for 45 seconds.

I would prefer to have the keyboard opened when the session starts and pay the price then, rather than randomly irritating the user the first time he/she tries to do input.

Alex Chiang (achiang) on 2012-10-24
Changed in newark:
importance: Undecided → High
Alex Chiang (achiang) on 2012-10-24
Changed in newark:
importance: High → Critical
Matt Fischer (mfisch) wrote :

ubuntu-defaults-nexus7 (0.24) quantal; urgency=low

  * rootfs/etc/X11/Xsession.d/90nexus7-a11y:
    - fix a typo in the Onboard theming settings
    - switch gsettings to not follow the system theme so that Onboard uses the
    right one (LP: #1070760)
  * rootfs/etc/init/nexus7.conf:
    - apt-get remove rhythmbox-ubuntuone since it causes rhythmbox to crash
    (LP: #1068959)
    - add the ubuntu-nexus7 public PPA (LP: #1069884)

Changed in newark:
assignee: nobody → Matt Fischer (mfisch)
status: New → Fix Committed
Alex Chiang (achiang) wrote :

On first boot after installation, we still use the Ambiance theme.

On all subsequent boots, the change in Xsession.d/ is picked up and we use the Blackboard theme.

Need to find a way to fix that first boot.

Changed in newark:
status: Fix Committed → Confirmed
Oliver Grawert (ogra) wrote :

we might miss a run of update-gconf-defaults in our Xsession.d script

Chris Wayne (cwayne18) on 2012-10-25
Changed in newark:
status: Confirmed → In Progress
Chris Wayne (cwayne18) wrote :

Verified fixed

Changed in newark:
status: In Progress → Fix Committed
tags: added: cqa-verified
Alex Chiang (achiang) wrote :

Our fix was to use the blackboard theme, which of course isn't really a proper fix at all.

Re-opening this so the upstream onboard devs can try their hand at some performance profiling. :)

information type: Proprietary → Public
no longer affects: newark
Changed in ubuntu-nexus7:
status: New → Confirmed
importance: Undecided → Medium
Matt Fischer (mfisch) on 2012-11-05
summary: - 1st time running onboard is painfully slow
+ 1st time running onboard with default theme is painfully slow
marmuta (marmuta) wrote :

Hmm, that's clearly not supposed to happen. I've expected Onboard to be somewhat sluggish on the Nexus 7 (though trunk should do noticeably better), but 45s? Can you confirm that Onboard is actually busy and using CPU during that time?
If you resize the keyboard, do you have to wait again for 45s?
The frame you see with the default theme, is it light gray with rounded corners, basically the background without the keys?
Try customizing the default theme (Ambiance), does it make a noticeable difference if you set shadow strength to 0?

Changed in onboard:
status: New → Incomplete
importance: Undecided → High
Francesco Fumanti (frafu) wrote :

Some performance enhancements have been implemented in trunk and I have made a build of the current trunk available in our snapshots PPA. You might want to give it a try:

Concerning the default theme: Onboard offers a facility to override the hardcoded default values by giving it other values in a specific file. Please have a look at the onboard-defaults.conf.example file also available in the source code package of Onboard for details.

Alex Chiang (achiang) on 2012-11-05
Changed in ubuntu-nexus7:
assignee: nobody → Chris Wayne (cwayne18)
marmuta (marmuta) wrote :

I've been able to test on a Nexus 7. Xorg fully occupies a single core during heavy cairo drawing while Onboard sits mostly idle and waits for drawing operations to finish.
The main culprits are gradients and drop shadows, turning these off makes themes somewhat usable.
The default backend for cairo seems to render purely in software, single threaded to boot, and it's simply too slow to do what Onboard needs. I'm going to run some experiments to see what we can do and possibly bypass cairo.

marmuta (marmuta) on 2012-11-07
Changed in onboard:
status: Incomplete → Confirmed
marmuta (marmuta) wrote :

I'll attach some cairo-perf results of Onboard starting up with the Ambiance theme. The Nexus 7 takes a whopping >200x longer than the i3 laptop. Single-threaded CPU performance just differs by a factor of some 4.5, and that number would probably have been ok with Onboard. 200x though, that's nothing we can make up for.
Adding cairo to the list.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in cairo (Ubuntu):
status: New → Confirmed
Mirzet Kadic (caracal-enl) wrote :

In general the keyboard is very slow IMO.

Sebastien Bacher (seb128) wrote :

Thanks marmuta for the investigation work, is there any chance you could open an upstream cairo bug about the issues you found? It feels weird that the cpu is several order of magnitude than an i3 still

Changed in cairo (Ubuntu):
importance: Undecided → Low

Created attachment 69773
cairo-perf results for Onboard starting up with Ambiance theme

I'm investigating why Onboard with the default theme takes upwards of 30s to start up on a Nexus 7 with Ubuntu 12.10. It's barely usable even with the simplest themes, where just a plain filled and stroked rectangle is drawn per key.

A cairo-perf-trace of Onboard starting up shows the Nexus 7 to be ~200x slower than a Sandy Bridge i3 laptop, but single-threaded CPU performance differs just by a factor of roughly 4.5 (see Attachment). Also the cairo image backends are vastly faster than the xcb/xlib one's, which is the reverse of the i3's results.

The Nexus 7 has a quad-core Tegra 3, me thinks the hardware isn't necessarily the limiting factor. Is this a driver issue? Xorg takes close to 100% CPU during heavy cairo rendering with (python-based) Onboard.

Here's the original bug report:

gtkperf on the Nexus 7:
GtkPerf 0.40 - Starting testing: Thu Nov 8 18:58:56 2012

GtkEntry - time: 0.77
GtkComboBox - time: 17.09
GtkComboBoxEntry - time: 6.95
GtkSpinButton - time: 2.42
GtkProgressBar - time: 2.91
GtkToggleButton - time: 7.59
GtkCheckButton - time: 2.12
GtkRadioButton - time: 3.66
GtkTextView - Add text - time: 6.94
GtkTextView - Scroll - time: 1.13
GtkDrawingArea - Lines - time: 12.66
GtkDrawingArea - Circles - time: 27.67
GtkDrawingArea - Text - time: 19.19
GtkDrawingArea - Pixbufs - time: 2.31
Total time: 113.47

libcairo2 1.12.2-1ubuntu2
nvidia-tegra3 binary Xorg driver 16.0-0ubuntu3

Created attachment 69774
cairo-trace --profile onboard

marmuta (marmuta) wrote :

I've opened an upstream bug here:

CPU performance isn't that bad, almost a quarter of the i3 per thread. It's apparently just cairo rendering to the xlib/xcb backends that takes the big hit. I'm not sure why, either the intel driver on the i3 accelerates cairo really well or the tegra driver does extremely poorly.
The weird thing is, cairo rendering to image backends is almost 10 times faster than to the x backends. I would try and exploit this to speed up Onboard, but then it would be the reverse on intel... Perhaps we need something closer to OpenGL for rendering, that's where the Tegra shines. I'm experimenting with a clutter right now

Are you sure that you want to report this against cairo-xcb? Because I am pretty sure that next to nothing uses this and certainly ubuntu doesn't by default. So I'm tempted to reassign this to cairo-xlib.

Oh and: It might be helpful to run your trace through cairo-analyze-trace (which is in the perf/ subdirectory). That should help identifying the slow operation.

Thanks, I wasn't sure which one to pick. You're right, the main context has a cairo.XlibSurface as target.

I'll attach the results of cairo-analyse-trace. That lookes very useful. If I understand the percentages right, I'd need to cut down on mask calls first and it was perhaps a good idea to cache gradient strokes and fills.
This is with Onboard trunk, btw.

Created attachment 69795
cairo-analyse-trace onboard.trace >onboard_ambiance_nexus7_analyse_trace.txt

The really interesting aspect of the trace is the where the drawing is nested 10s of levels deep (>50) with all the results being kept around in a stack until they get masked onto the output. It's certainly the first time I've seen that pattern in a trace, and it may indeed be the right approach for you, but it looks inefficient.

Also you have to be aware that you will be limited by driver quality when using cairo-xlib, which is likely to be a contributing factor as well as the hw differences for comparing SNB to the Nexus7.

Hmm, there shouldn't actually be more than five or so nesting levels, the first probably being GTK's double buffering. How can I read the levels from the trace? I assumed it somehow repeats at Observing '/home/ubuntu/onboard.trace'...., are those nesting levels too?
Most of the nesting happens only occasianally, i.e. on startup, resizing, etc. and is then masked to the main context all other times. Drawing all the keys at once with shadows and gradients turned out too slow even on non-mobile devices, hence all that caching.

Driver quality is what I'm afraid of. Would that explain why the image backends in the first attachment are so much faster than cairo-xlib?

My guess for nesting levels comes from reading the trace, and in particular the use of '51 index set-source' implies that are roughly 20 or so surfaces in the stack.

Yes, I use the relative speed of cairo-image to cairo-xlib to judge driver quality. (No driver implementation should be slower than is possible using the cpu...)

Thanks for the hints, that helped. Apparently deep nesting happens when patterns are shared between contexts. I'm not sure if this was a save thing to do at all. I've switched them to surfaces and now there are no high index values in the trace anymore.
I had hopes, but unfortunately this did nothing for the performance issue, it may even do slightly worse.

Bypassing the driver does make a difference, though:
$ ./onboard
draw 13635.882ms

$ GDK_RENDERING=image ./onboard
draw 1371.348ms

That number is the initial caching plus the first redraw. That's probably already good enough for the startup, but not yet for all later interaction. From there on python/python-gi show up as bottlenecks too.

marmuta (marmuta) wrote :

Good news, I've been able to squeeze some more performance out of Onboard, with a lot of optimizations and a little bit of corner cutting. A warm start with Compact+Ambiance is down to around 6 seconds. The other themes a second or so less. Most typing has become more fluid too, the delays on modifier presses and layer switches are shorter most of the time. The splash-screen like empty frame on startup is gone, Onboard just pops into existence when it's ready.
I'll mark the Onboard part as committed, but more speed improvements will likely come over time.

Changed in onboard:
status: Confirmed → Fix Committed
Matt Fischer (mfisch) on 2012-11-13
Changed in onboard:
assignee: nobody → marmuta (marmuta)
Chris Wayne (cwayne18) wrote :


Is there a ppa where I can try out these fixes? Thanks!

marmuta (marmuta) wrote :

Sure, I'll ask Francesco to make a snapshot of trunk, he'll post here when it's ready. Feedback is very welcome. There's some new stuff too, multi-touch support and rudimentary docking (still working on that).

A note of precaution: trunk rev. 1069 seems safe to install on the Nexus 7, I just did, but for anything outside of releases it's probably wise to have some alternative keyboard input/auto-login ready.

Francesco Fumanti (frafu) wrote :

Reply to comment 16 and 17:

By default, the ARM builds in PPAs are only available for projects from Canonical, so I posted a question on launchpad to ask the to enable it also for our PPAs (the PPAs of the Onboard devel team https://launchpad.net/~onboard).

I am waiting for my request to be accepted or declined (it usually does not take long to get an answer) and will then upload the Snapshots.

Alex Chiang (achiang) wrote :

We could upload this for you to the ubuntu-nexus7 PPA which is enabled for ARM.

Is this something you'd like us to do?


Francesco Fumanti (frafu) wrote :

My request has been declined, unfortunately:

I just uploaded revision 1071 to our Snapshots PPA:

It should however not be to difficult to build the ARM, if you fetch the package from our PPA:

- Enable the Snapshots PPA

- Get the Onboard source from the PPA (I think that it gets the most recent version from all the available repositories; it is the version in the PPA at the moment):
$ apt-get source onboard

- Get the the packages needed to build Onboard (root privileges are required as it might install packages):
$ sudo apt-get build-dep onboard

- Change directory to the downloaded Onboard folder:

- Call the command to build the debian package of Onboard (Unless you created a new debian/changelog entry with your own key, you should get signing errors at the end of the build of the package; you can ignore them.):
$ debuild -tc

- Double click on the created deb to install it.


As I don't have a table, could you please test of the steps indicated above are working on your tablet? Thanks.

Alex Chiang (achiang) wrote :

Scott, can you please grab the package from the PPA and see about an upload to the ubuntu-nexus7 PPA (after ensuring it builds for us, etc.)


Changed in ubuntu-nexus7:
assignee: Chris Wayne (cwayne18) → Scott Sweeny (ssweeny)
Francesco Fumanti (frafu) wrote :

@ Chiang

Many thanks for your offer. It will be great if you upload it to your PPA. But please, be aware that it is a Snapshot of revision 1071 of trunk; it is not a release. It should however already contain noticable improvements for the Nexus 7 compared to the release in the raring main repository.

May I contact somebody of the ubuntu-nexus7 team when there is another version available for the PPA and if so, how to best contact you?

Changed in cairo:
importance: Unknown → Medium
status: Unknown → Confirmed
Scott Sweeny (ssweeny) wrote :


I've verified that your package builds and works on the device, and I'm preparing to upload it to our PPA.

Can you tell me what you expect the next release number to be? 0.98.3? 0.99? I wan to ensure a smooth transition between the PPA package and the eventual release.

Francesco Fumanti (frafu) wrote :

Hi Scott,

Thanks for making the package available in your PPA.

The next release superseeding the 0.98.2+tr1071 package that you are going to upload to your PPA will be 0.99.0.

Onboard 0.98 is our current stable branch. It is not excluded that some day a 0.98.3 version with bug fixes for the 0.98 branch will appear. But it will not contain the improvements for the Nexus 7 that are currently in trunk. These will be available from the 0.99 branch, which will be created from trunk, when the changes for the Nexus are going to be released.


Scott Sweeny (ssweeny) wrote :

The snapshot package is now available in the Nexus 7 PPA.

Francesco, please feel free to ping me on IRC or by email with any updates.

marmuta (marmuta) wrote :

could we get python3-virtkey updated to 0.62.0 in the Nexus 7 PPA too? This would allow Onboard to show proper key labels for the number block and fix the action of the NumLock key.
Raring has it already (0.62.0-0ubuntu1), though I've only now updated Onboard's version requirements.
Built from source, it works alright with Onboard 0.99-tr1071-0nexus7.1 and current trunk on my Nexus 7.

Scott Sweeny (ssweeny) wrote :


I've uploaded the virtkey package to the Nexus 7 PPA as well.

Changed in ubuntu-nexus7:
status: Confirmed → Fix Released
marmuta (marmuta) wrote :

Scott, thank you. it works here after update and fixes the issues.

marmuta (marmuta) on 2012-12-22
Changed in onboard:
status: Fix Committed → Fix Released

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/236.

Changed in cairo:
status: Confirmed → Unknown
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.