|
Bugzilla – Full Text Bug Listing |
| Summary: | Installation: Loading the Timezone dialog could be faster | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.1 | Reporter: | Lukas Ocilka <locilka> |
| Component: | YaST2 | Assignee: | Stephan Kulow <coolo> |
| Status: | RESOLVED WONTFIX | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Enhancement | ||
| Priority: | P5 - None | CC: | coolo, jsuchome |
| Version: | Alpha 0 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
YaST log
test case |
||
This is strange, code in constructor should be evaluated only once. I'll investigate. The problem is not in initialization (constructor code is called once), but when the time zone entries are sorted according to current language. I can do some optimization, but it won't be much better. One thing that could help visually would be to open the dialog soon and fill the widget data once they are ready. But TimezoneSelector doesn't support changing/entering `Items (via ChangeWidget) after it is shown. Coolo, could you add it? provide me with a ycp test case and assign it to me Created attachment 223947 [details]
test case
Well, OK, I could do the same thing with UI::ReplaceWidget, so implementing `Items property might have sense only when it is faster than replacing whole widget....
Just decide yourself if it is worth the work. I would expect replacing the widget to be more expensive as the worldmap needs to be loaded and scaled twice then. ok, I experimented with your test case and if you take out the event loop, you get a test case that can be timed with "time y2base" - I get around 1.4s-1.7s with just showing a blank timezone and around 1.5s-1.9s with having the replacewidget call in. So at least on my hardware, the effort to implement changewidget doesn't seem to be justified. I look how hard it is. I missed the time so far and I doubt I find the time to save 0.1s. so I go WONTFIX |
Created attachment 219157 [details] YaST log Loading the Timezone dialog in installation takes some time that users are not informed what's happening. For a normal installation, this is only once, but when you go back and forward the dialogs, the initialization is always the same. This is mostly because the Timezone module doesn't remember being already initialized. For a simple solution, this could be used: --- cut --- boolean initialized = false; void Timezone () { if (initialized) { y2milestone ("Already initialized"); return; } ... } --- cut --- See the last few lines of YaST log. The logs comes from going_back=true. Note: this is on a VERY fast hardware :) ;) You see some longer delays on a normal HW. If the _already_initialized_ patch is used, we could import the Timezone when installation is initialized (with a Progress dialog) so that would speed-up even the fist-dialog loading.