resizing language selector window consumes 100% procesor power

Bug #533216 reported by Matej Svetlík on 2010-03-06
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
language-selector
Invalid
Undecided
Unassigned
language-selector (Ubuntu)
Low
Unassigned

Bug Description

When i try to resize Language Selection window (System/Administration/Language Support) resizing is very laggy and consumes a lot of processor time. It only happens when _language_ tab is selected. When in _text_ tab resizing works as expected. Portably redrawing language list on first tab is too much CPU intensive.

Arne Goetje (arnegoetje) on 2010-03-18
Changed in language-selector:
status: New → Invalid
Arne Goetje (arnegoetje) wrote :

Resizing is fine for me, although it does use quite a bit of CPU cycles, it is not laggy on my machine.

Not sure what to do with this bug report.

What kind of CPU do you have?

Changed in language-selector (Ubuntu):
status: New → Incomplete
Matej Svetlík (matej-svetlik) wrote :

my CPU is Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz.

I found better way how to reproduce this "bug". First Open Language Support window and maximize it. Then open some other window (e.g. gnome-terminal) and move it in front of language selector. You can see that list of languages redraws very slowly. I tried it with some other windows which has large list of items (synaptic, update-manager) and the redrawing of lists was very fast. Or when you move mouse fast over the list of languages higlighted row lags behind mouse movement because the list is unable to redraw fast enough.

Language list seems to be custom drawn widget ... so i assume there is something slow in the redraw function.

In the "language for menus and windows:" list I got 18 languages ... two active and other inactive (gray).

Matej Svetlík (matej-svetlik) wrote :

I tried to look at source code of language selector

in the file GtkLanguageSelector.py there is a method def setupLanguageTreeView(self) and in this method there is a call to "column.set_cell_data_func (renderer, lang_view_func)" if i comment out this function redrawing of the list becomes fast. So there is probably something strange in the lang_view_func. But i don't understand yet what this function is doing :D.

Arne Goetje (arnegoetje) wrote :

Thanks for analyzing this. :) Now I know where to look at.
However, I'm not sure right now how to solve this, since we cannot just order all entries alphabetically, but need to put the active entries, sorted by the user, in the beginning. The following inactive entries can then be sorted alphabetically. The current code used bubble-sort for this.

Changed in language-selector (Ubuntu):
status: Incomplete → Triaged
importance: Undecided → Low
Matej Svetlík (matej-svetlik) wrote :

what about replacing the list with a few selectboxes? Something like my primary language, secondary language and so on? It seems quite non-intuitive to drag and reorder the list. It took me a few moments to find how it works and half of the informations is hidden in a huge tooltip.

Matej Svetlík (matej-svetlik) wrote :

problem is that lang_view_func is called every time the list row needs to be redrawn ... and every time the markup for every row is reseted ... even worse self._localeinfo.translate function is called for every row (this function seems to be quite expansive)

solution:
because row color can be changed only by dragging rows, row colors should be changed only as a response to drag event

Arne Goetje (arnegoetje) wrote :

OK, thanks for info. I'll see what I can do until 10.04beta2 to improve this.

Changed in language-selector (Ubuntu):
assignee: nobody → Arne Goetje (arnegoetje)

FYI I experienced this in both 9.10 and 10.04 beta. And I agree with #5 that how this list works is less than obvious and that the huge tooltip probably isn't the right place to hide the instructions.

Arne Goetje (arnegoetje) on 2010-04-15
Changed in language-selector (Ubuntu):
milestone: none → lucid-updates
Arne Goetje (arnegoetje) on 2010-09-06
Changed in language-selector (Ubuntu):
assignee: Arne Goetje (arnegoetje) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers