After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 638970 - Loading a new profile takes longer than ideal
Loading a new profile takes longer than ideal
Status: RESOLVED FIXED
Product: orca
Classification: Applications
Component: general
2.91.x
Other All
: Normal normal
: ---
Assigned To: Joanmarie Diggs (IRC: joanie)
Orca Maintainers
profiles
Depends on:
Blocks: 491756
 
 
Reported: 2011-01-08 07:14 UTC by Hammer Attila
Modified: 2013-01-02 15:50 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Debug file with shows the download process (174.06 KB, application/octet-stream)
2011-01-08 07:16 UTC, Hammer Attila
  Details
First revision this fix (43.58 KB, patch)
2011-01-08 07:53 UTC, Hammer Attila
reviewed Details | Review

Description Hammer Attila 2011-01-08 07:14:49 UTC
Dear Developers,

When the user clicking the load button (would like load a profile), and clicking the yes button, about five seconds nothing happened, because Orca loading new settings with new choosed profile.
I think need a following style notification with speech and braille display:
"Download in progress, please wayt..."

I attached a debug.out with show the entire now using download method.

Attila
Comment 1 Hammer Attila 2011-01-08 07:16:29 UTC
Created attachment 177805 [details]
Debug file with shows the download process
Comment 2 Hammer Attila 2011-01-08 07:53:46 UTC
Created attachment 177806 [details] [review]
First revision this fix

This patch add a notification message after the download profile message dialog is destroyed if the user clicked the yes button.
The notification message spokening with System voice and presenting the braille display. This message notify the user need wayting until the load profile operation is not finished.

If my fix method is good, please commit this patch.

Attila
Comment 3 Trevor Saunders (IRC: tbsaunde) 2011-01-15 01:41:57 UTC
Why don't we just make loading the profile faster?  5 seconds to do this seems insain.
Comment 4 Joanmarie Diggs (IRC: joanie) 2011-01-15 01:57:40 UTC
It's on my to-do list Trev. Although for me it's not as long as 5 seconds. Regardless, that is the desired solution; not a notification.
Comment 5 Joanmarie Diggs (IRC: joanie) 2011-01-15 01:58:55 UTC
Review of attachment 177806 [details] [review]:

Thanks for doing this Attila. However, as I've commented just now, the solution is to figure out why things are taking so long; not announce that fact.
Comment 6 Hammer Attila 2011-01-16 10:00:46 UTC
Not profile related, but before I reporting following issues, anybody not known this issues already reported prewious a bug?
The Orca application preferences dialog some time is very slow with some applications.
When for example I opening simple Orca application-specific preferences window for Yelp and simple close the dialog with Esc key, I need wait I think 12 second before Orca begin talking again.
I see equals 12 second time value with Firefox, Thunderbird. In gedit if I opening Orca application-specific preferences dialog and close the dialog, I need waiting only 8 second before Orca speaking again. I not change this tests any preference.
The interesting is following:
For example if I opening normal Orca preferences dialog if Firefox or Yelp running, I need waiting only 3 second after I close the Orca preferences dialog with Esc key. This is true Thunderbird and gedit too.
Anybody confirming this issues with simple tests without changing any preference?
Simple launch applications, and try opening and close Orca preferences dialog with Orca+space key and Orca application-specific dialog with Orca+Ctrl+Space key combination, and compare how many seconds need waiting if you close the opened dialogs before Orca speaking again.

Attila
Comment 7 Joanmarie Diggs (IRC: joanie) 2011-01-16 16:26:21 UTC
Part of the problem with loading profiles taking longer than it should is we have an old (from 2006) line to sleep for a full second. I've just removed that. Settings/profiles continue to load and reload just fine from my tests. So I've just committed that change.

http://git.gnome.org/browse/orca/commit/?id=354fdb8890678a195f9e7cea04f5eb9e6e3cee2e

Note also that I compared the current master with one of my local, refactored branches that I hope to commit soon. In my refactored Orca, profiles load faster. So that, too, will help out with this bug.

I'll look now for any additional delays where some time might could be saved.
Comment 8 Joanmarie Diggs (IRC: joanie) 2011-01-16 16:29:43 UTC
(In reply to comment #6)
> Not profile related, 

Please report new issues on new bugs. Otherwise, when existing bugs get fixed and closed, your comments will get forgetten. And I don't want to forget the issues you report, but I do want to focus on one issue at a time. Thanks!
Comment 9 Joanmarie Diggs (IRC: joanie) 2011-01-16 17:07:49 UTC
So from some more testing, in which orca.loadUserSettings() was timed using my local branch, the total time spent in that method was 0.25 seconds. And there was not one main culprit; instead the total time was divided amongst the various things needed to be done. A bit more time was taken by the xmodmap stuff, which Ale (I think) has plans to get rid off. Given that, and the fact that the performance analysis work is about to begin, I'm going to add this to the performance metabug.
Comment 10 Hammer Attila 2011-01-16 18:02:20 UTC
Joanie, thank you the answer and the commit.
I see now following if I loading a profile after I recompiled full updated Orca:
I need wayt only 4 second after clicking yes button, the 5th second Orca begin speeching again.
I don't no now original time values is how many second.

Attila
Comment 11 Joanmarie Diggs (IRC: joanie) 2013-01-02 15:50:13 UTC
In the recent changes made to Orca to add a keybinding to switch languages via profiles, the switch is pretty performant. In fact, on one of my older machines, it's more or less immediate. So closing this as FIXED.