Onboard uses CPU so high

[mrDoctorWho]

Onboard uses CPU (1.6Ghz dual-threading Intel Atom) so high while i pressing buttons on it . On press a button on it, it load CPU for 30-40% and Xorg start using 20% (default no more than 7). Also, when moving it at display it uses CPU for 20%, and when full CPU load by another programms more than ~=75%, onboard loses order of the letters and sometimes have lag with last pressed button: it sticks and pressing more than 1 time (but really pressed one)

P.S. Sorry for my English. If you don't understand me, just tell me it and i try to rewrite this text.

[marmuta (marmuta)]

Thanks for the separate bug report.

Is this still Onboard v0.98?
$ apt-cache policy onboard

on Precise?
$ lsb_release -a

Which Onboard theme are you using? "Ambiance", the default is the most demanding, "Classic Onboard" the least. The difference might not be large, though. What's the CPU load with "Classic Onboard"?

Run this please with the "Ambiance" theme selected:
$ top -bi | grep -e '^[t 0-9]' | tee top.txt

While this is running, at first just move the mouse pointer around over Onboard for a couple of seconds.
Then start typing a single letter as fast as you can, don't care for missed key strokes.
Then do nothing for another 10 seconds.
Press Ctrl+C and attach the resulting file "top.txt" here.

[mrDoctorWho (mrdoctorwho)]

Oh, i'm so sorry, but it's onbord 0.97. But it's a lastest in ubuntu ppa. I also tried this ppa: ppa:onboard/snapshots, but apt write that it can't be installed because dependence can not be satisfied (python3-virtkey).

There are what do you want:
# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 12.04.1 LTS
Release: 12.04
Codename: precise

Theme: Droid. Changed to Ambiance.

[marmuta (marmuta)]

Thanks that was quick. I think the CPU spent on Onboard is not too far away from what I would expect on an Atom, typing takes 10-12% on my i3 laptop. Xorg at one point using more than Onboard seems unusual, though. I've seen video driver issues in the past that would cause this.

Onboard isn't exactly lightning quick, we should do some more optimization in the future. In my testing 0.98 is a little bit faster than 0.97, but it probably won't be enough to stop the key repeats. 0.98.1 should finally be able to run on Precise too, Francesco will most likely update the PPA soon and let you know.

Some things you can do now:
- increase the key repeat delay in system settings->keyboard (or the xfce equivalent)
- switch to a layout without gradients, for example "Classic Onboard" or if you hate that, which is entirely possible, customize your favorite one and set "Key Style" to "flat"
- Advanced: run sudo sysprof to see if there is some easily identifiable video driver issue. If you like you can attach the saved profile data here for me to have a look. Make sure to keep Onboard busy at least for 20 seconds while it is collecting samples.

[marmuta (marmuta)]

I made some progress on this. Trunk should roughly cut the CPU usage in half during most typing and when just moving the pointer over the keyboard.

[Francesco Fumanti (frafu)]

I have uploaded the development version of Onboard containing the CPU usage improvements to our Snapshots PPA for precise and quantal:
https://launchpad.net/~onboard/+archive/snapshots

[David López (david-lopez-upct)]

Hi. I have a wetab clone tablet (1,66 GHz Intel Atom N450 processor, 2GB RAM). I have tested stable onboard 0.98.1 and current onboard trunk, both of them comipled from sources in 64bits archlinux with LXDE/openbox.

I've tried to record a graph of the CPU usage, but I only know pscpug package and it's programmed to stop when pressing keys :-D, so it's unuseful to test onbord. I collected data looking at lxtask, don't expect accuracy values. I've compared Ambiance, Classic and ModelM themes, one time typing at my normal speed (3-4 keystrokes per second) and another time crazy as hell (typing 'kdfuhdyfyfbfyfhdjdu' and that kind of things as fast as I can :-D). I also computed hiding/unhiding CPU values

Stable 0.98.1:
- Ambiance
--- (hiding): 5% CPU
--- (unhiding): 21% CPU
--- (normal speed): 20-25% CPU
--- (crazy as hell): 40-45% CPU
- Classic
--- (hiding): 4% CPU
--- (unhiding): 10% CPU
--- (normal speed): 15-25% CPU
--- (crazy as hell): 35-40% CPU
- ModelM
--- (hiding): 4% CPU
--- (unhiding): 22% CPU
--- (normal speed): 35-40% CPU
--- (crazy as hell): 45% CPU

Trunk version:
- Ambiance
--- (hiding): 3% CPU
--- (unhiding): 19% CPU
--- (normal speed): 15-20%
--- (crazy as hell): 25%-30% CPU
- Classic
--- (hiding): 3% CPU
--- (unhiding): 9% CPU
--- (normal speed): 10-15% CPU
--- (crazy as hell): 20-25% CPU
- ModelM
--- (hiding): 3% CPU
--- (unhiding): 22% CPU
--- (normal speed): 20-25% CPU
--- (crazy as hell): 35-45% CPU

Trrunk version is an advance in CPU cost when typing, maybe not cut in half (sorry marmuta :-( ) but big improvement without trace of doubt.

Upgrading to ubuntu 12.04 from 11.10 was a performance nightmare for me, for example unity or nautilus in 12.04 were very, very slow in my tablet. I had to move to lighter systems (first to lubuntu 12.04, then to arch with lxde) but it was not onboard responsability. I miss some features that doesn't work in lxde (auto-show on edit and tansparences) but to be honest the onboard speed is acceptable for me (*).

(*) I have experimented mutiple press bug (sssssssssssssssomething like thhhhhhhhhhhhhhat) from time to time in stable 0.98 onboard, but honestly I don't know if it's a lag problem. I will be alert in this new trunk version to check if the problem persits.

[David López (david-lopez-upct)]

I can confirm both bugs in the trunk version: the multippppppppppppppppple press and the mssng keys issues :-) However my CPU ussage wasn't very high when I suffer them (I have an applet in my desktop to watch CPU load) , I still doubt those bugs are related with CPU ussage.

[mrDoctorWho (mrdoctorwho)]

0.98.1 is better than 0.97. Lags exists, but now is better.

[mrDoctorWho (mrdoctorwho)]

60% on pressing... (onboard 0.98.1)

[marmuta (marmuta)]

@David, awesome, thank you for testing. The largest improvement was with moving the pointer over Onboard, so I'd expect typing on a touch screen to benefit somewhat less. On my non-touch i3 notebook, crazy pointer motion went from >30% to 12% and hitting a single key as fast as possible from 10-12% to 6.5-7% (Ambiance theme, only Onboard's CPU share).

@mrDoctorWho, just to be sure, did you install 0.98.1+tr984-0ppa~precise~sysdef1 or later from the above snapshot PPA? That one is straight from the development branch (trunk). The regular 0.98.1 release doesn't include the optimizations.
Now that we have another Atom to compare, 60% CPU load looks pretty abysmal. I wonder what's going on. Is that total system load, everything + Onboard? Hitting a single key like crazy without pointer movement? Droid theme? Is that a NVIDIA ION system or does it have the regular Intel IGP?

@both, when Onboard loses key strokes, does that happen anywhere at random? There is still an open bug with firefox' location bar and similar text-entries with popups where it happens to everyone:
https://bugs.launchpad.net/onboard/+bug/905636

All I know about the repeating key issue is, that it happens due to some kind of lag, caused by Onboard and/or by the rest of the system. I'll try something different. I think we have to either get Onboard's worst case latency reacting to button releases down, or allow to turn off key repeat.

[mrDoctorWho (mrdoctorwho)]

@marmuta, Onboard 0.98.1+tr987-0ppa~quantal~sysdef1 (i switched my system to Quantal, beta-2 at now) from here https://launchpad.net/~onboard/+archive/snapshots. CPU load only for onboard (top), droid theme At movement onboard takes 73%. GPU: Intel GMA950, CPU: Intel Atom N270. Installed ppa:xorg-edgers

Loses key strokes on firefox, also loses sequence of letters.

Also when use onboard, CPU using by Xorg increases to 20-30%.

[mrDoctorWho (mrdoctorwho)]

At crazy layout switch onboard uses more than 80% CPU. I understand it, program need to render more buttons and connect signals to everyone button. I don't think that python is better choice for it becaues it's not fast.

[marmuta (marmuta)]

@mrDoctorWho, I have no explanation for 73% CPU while moving the pointer over Onboard. There are no screen updates then, and the active theme doesn't matter. Turning off tooltips in preferences may help a little bit, though.

What's the output of
$ python3 -m test/pystone
My laptop gets roughly 90000 pystones/second

Switching layouts in preferences is expensive, enough to make it a bit slowish here too, but I don't feel that really needs to be improved. I'm trying to optimize for the most common cases during regular usage, i.e. typing.

Python is only partly to blame. A lot of time is spent in cairo amd GTK (and python-gi). Antialiased labels, rounded rectangles and gradients would slow down rendering in C too.

[marmuta (marmuta)]

I'm ready for the next iteration. Trunk rev. 995 has two major changes. First, drawing keys should be faster again, CPU load ought to go down a bit for most key presses. Second, it has some experimental code to reduce the risk for repeated keys. It's difficult for me to simulate Atom conditions, so I'd appreciate if you'd help with testing.

@Francesco, if you find the time, would you please update the snapshots PPA for mrDoctorWho? Thanks in advance.
@mrDoctorWho, please update to snapshot 995 once it arrives
@David, please update your local branch with bzr pull.

To enable the low-latency code, run Onboard like this:
$ onboard --low-latency
Then let me know if this makes is harder to get repeated keys. If that helps and doesn't break anything important, I'll make it the default. Note: screen updates of Onboard's keys may be somewhat delayed.

[mrDoctorWho (mrdoctorwho)]

@marmuta,
$ python3 -m test/pystone
Pystone(1.1) time for 50000 passes = 2.62
This machine benchmarks at 19084 pystones/second

[mrDoctorWho (mrdoctorwho)]

I'm python programmer and don't understand: why python3?

# Python 3
$ python3 -m test/pystone
Pystone(1.1) time for 50000 passes = 2.62
This machine benchmarks at 19084 pystones/second

# Python 2
$ python -m test/pystone
Pystone(1.1) time for 50000 passes = 2.25
This machine benchmarks at 22222.2 pystones/second

[mrDoctorWho (mrdoctorwho)]

@marmuta, not pointer, i mean crazy move onboard with pointer. And can you update onboard in ppa? Or i need compile from source?

[marmuta (marmuta)]

You can build it from source. This is relatively easy to do on Quantal now, since v0.98 is in the repos:
$ sudo apt-get build-dep onboard
$ bzr branch lp:onboard
(optionally run: "debian/rules python2" to switch to the python2 version, you'll have to install dependencies manually then, though)
$ ./setup.py build
$ ./onboard <- runs it from the project directory

If you're ready to install, do:
$ debuild binary
$ sudo dpkg -i ../onboard*.deb

We've been trying to switch to python 3 for a while because of the more consistent Unicode support. There was a lot of pain with translations crashing Onboard. Ubuntu made a push to python 3 in Quantal so we happily went along with this.
The speed hit isn't consistent, sometimes python 3 is ahead, pystone doesn't show the whole story. Onboard can optionally still run with python 2, though.

Do you mean moving the window with the move button? That may go to 100% CPU even on slow systems (custom code to allow it to work with auto-show.). See also bug https://bugs.launchpad.net/onboard/+bug/959035. Since then resizing has become more efficient, but I have no good idea how to improve moving.

[Francesco Fumanti (frafu)]

There is a regression in revision 995: activating a modifier does not update the layout. This is especially visible with the Shift modifier and the row with the number keys not changing. The auto-release of the modifier is not working either as it should. I am only talking about what Onboard is showing; it continues to honor the state of the modifier for the letter that gets typed.

Should I wait for a fix before uploading a new revision to the Snapshots PPA?

[Francesco Fumanti (frafu)]

My i5 tower:

$ python3 -m test/pystone
Pystone(1.1) time for 50000 passes = 0.48
This machine benchmarks at 104167 pystones/second

$ python -m test/pystone
Pystone(1.1) time for 50000 passes = 0.45
This machine benchmarks at 111111 pystones/second

[mrDoctorWho (mrdoctorwho)]

I update to last rev from bzr and see that onboard going better. But sometimes i see pressing reperat when CPU is not overloaded

[Francesco Fumanti (frafu)]

@marmuta

The following is probably relevant for the modifier updating problem, as the problem does not occur under the login screen with the default modifier behaviour:

$ gsettings get org.onboard.keyboard sticky-key-behavior
{'all': 'dblclick'}

[Francesco Fumanti (frafu)]

I just uploaded revision 996 of trunk to the Snapshots PPA for quantal and precise and it should be available as soon as launchpad has finished building it.

[marmuta (marmuta)]

@Francesco, thanks, should be fixed now. Modifier updates were broken with all sticky key behaviors. There is another issue with the window disappearing occasionally when toggling force-to-top or window decoration. I'll look into this another time.

I think you can wait with the snapshot, mrDoctorWho is running from source too now.

@mrDoctorWho, great, we're making progress. There might be spikes in CPU usage that don't show up in top's load average. I've turned the garbage collector off between key press and key release now, maybe that helps. Please update your branch (bzr pull) and try again.

Does it make a difference if you run with or without the --low-latency option? Are key repeats less frequent with --low-latency?

[mrDoctorWho (mrdoctorwho)]

@marmuta, lastest onboard at 15.10.2012 17:24 (GMT+7) with "--low-latency" don't reperat pressing when CPU overloaded

[marmuta (marmuta)]

Great, success at last!
I've made the low latency hack the default now, we'll see how it goes. There is some time left for testing until the next release.
I'll leave this bug at "Fix Commited". If you still have problems with CPU usage, reopen it please.

We'll track CPU use when moving the keyboard here:
https://bugs.launchpad.net/onboard/+bug/959035

and lost key strokes in firefox and other popup entries there:
https://bugs.launchpad.net/onboard/+bug/905636
(unrelated to CPU usage)

I currently have no good idea how to fix either of them, though.

[mrDoctorWho (mrdoctorwho)]

So, ok. Thank you all. I try lastest onboard now. Also exists a Xorg bug (it uses 30-60% CPU while pressing buttons on onboard). Should i open it? I don't think that Xorg developers are very responsible.

[marmuta (marmuta)]

You can try, but be sure to read through these:
https://wiki.ubuntu.com/X/Reporting
https://wiki.ubuntu.com/X/Debugging

From my own experience they are mostly concerned about crashes or similar crippling conditions. There is a huge list of those, so temporary 30-60% CPU usage will probably get buried unless a large number of people are affected. Chances are bug reports for low performance on everyone's video chip set exist already, though. Try searching xorg bugs for intel 950.

[marmuta (marmuta)]

FYI, the low-latency experiment caused Bug #1068899 and I had to revert it.
On to plan C, then. Trunk now simply finishes drawing before a key-press is sent. This ought to actually be more effective in preventing key repeats than the previous try.

@mrDoctorWho, if you get the chance, please try trunk again and let me know if you get unwanted key repeats. I have a feeling it will be a lot harder to get them this time.

[mrDoctorWho (mrdoctorwho)]

@marmuta, Hi, I'm sorry for long mute. I tested lastest onboard (1049) at 04.11.12. Warn: I tested without "--low-latency" option. And yes, i have this problem, but not so hight like previous versions. Now on another laptop (Intel Atom N450@1.67GHz, Intel GMA 3150, on old laptop physical keyboard died fully). Also 70% CPU using on resize

[marmuta (marmuta)]

Thanks for testing, mrDoctorWho. If you say you still have this problem, do you mean keys repeating or high CPU usage? The --low-latency option is gone, you did well testing without.

Resizing is actually supposed to take 100% CPU for Onboard+Xorg. Question is, is it smooth enough for interactive resizing? It should be noticeably faster with revision 1022 and later. Do you get reasonable interactive frame rates or is it still too jerky?

[mrDoctorWho (mrdoctorwho)]

@marmuta, i mean key's reperating when cpu load ~=70%. I think that it reasonable interactive frame rates, not too jerky.

[Francesco Fumanti (frafu)]

The fix is available in the alpha 1 preview release of Onboard 0.99.0. Thus, I am marking this bug as Fix Released. Please, do not hesitate to reopen it or file a new bug if this problem is still an issue for you.

onboard (0.99.0~alpha1~tr1190-0ubuntu1) raring; urgency=low

  * New upstream alpha release. (LP: #1089396)
    + Fix Onboard becoming empty when system font dpi changes

 -- Francesco Fumanti <email address hidden> Wed, 12 Dec 2012 21:33:43 +0100

onboard (0.99.0~alpha1~tr1188-0ubuntu1) raring; urgency=low

  * Sponsorship request for Ubuntu Raring (LP: #1089396)
  * debian/control: raise virtkey run dependency to 0.63.0 or above
  * debian/patches: refresh patch and change default theme
  * Onboard requires now virtkey >= 0.63.0
  * Add example file with system defaults for the nexus7
  * Various changes to get acceptable speeds on the nexus7 (LP: #1070760)
  * Add docking feature (LP: #405034)
  * Add sliding feature for docking and auto-repositioning
  * Add multitouch support
  * Add a toggle to stop listening to touch events in case of many problems
  * Add popup on long press for key variants like diacritics
  * New option to choose popup vs repeat for keys with variants
  * New gsettings key for the popup delay
  * Make move, frame and touch handles work on the nexus7
  * Perform simulated clicks on correct touch position
  * Auto-release pointer grab after timeout in case nexus7 is unresponsive
  * Fix xserver memory leaking
  * Improve speed when typing and moving the pointer (LP: #1055448)
  * Fix rendering being slowed by emboss effect on keycaps (LP: #890221)
  * Fix for not being able to move/resize Onboard on touchscreens (LP: #959035)
  * Have Onboard respect launcher icon size (LP: #1078554)
  * Auto-show Onboard by clicking already selected text entries (LP: #1078602)
  * Make default shortcut for language/layout work from Onboard (LP: #1078629)
  * New design of the Preferences dialog with more options (LP: #1053496)
  * Disable click buttons when mousetweaks is not installed
  * Add D-Bus service to show and hide the keyboard (LP: 1032042)
  * Don't export dbus service for embedded instances
  * Set NumLock's default sticky behavior to LOCK_ONLY
  * Keep state of NumLock across restarts
  * New attribute in layout files for sticky key behaviour
  * New layout tags key_template and keysym_rule defining keysym-specific labels
  * New window tag for color schemes to define border of popups
  * New layout tag for language specific overrides in the layouts
  * Move common key definitions into template for import by layout files
  * Sync modifier states of Onboard with changes by hardware keyboard or tools
  * Fix keys not re-rendered when releasing latched modifiers (LP: #1069990)
  * Send key strokes for all modifiers (LP: #1067797)
  * Blacklist Ctrl-LAlt+Fn keys by default
  * Add alternative key generation by at-spi2
  * Try to improve struts handling for metacity and mutter
  * Fix getpreferredencoding hack, by Matthias Klose
  * Build for all python3 versions, by Matthias Klose
  * Add work arounds for some problems with the search box of firefox
  * Improve startup sequence to fix Onboard showing up so...