I have a basic idea of how the start up loading time could be reduced. I don't know if the gain would even be measurable, and if not, just WONTFIX this. Anyway, from what I can see with my bare eyes, it appears that all toolbar buttons and bookmarks are fully loaded and placed on the toolbar when the window is first displayed on screen. I can only assume that loading and placing all the buttons on the toolbar takes at least 1/10th of a second, and possibly more than that. My idea on how the startup speed could be slightly increased is to paint the window before actually loading the toolbar and processing the bookmarks.htm file. Since I haven't seen the code for Phoenix, I can only assume that it could take long to process a large bookmarks.htm file, and since the personal toolbar data is stored inside that file, the startup speed must suffer. I am a programmer myself and I have made a text editor with customizable toolbars. Since startup speed is very important in a text editor, I have managed to reduce the startup time by painting the main window before actually loading all the buttons in the toolbar. The placeholder for the toolbar is there, but the actual buttons are not loaded until afterwards. This gives the impression that it starts faster than it actually does.
I just noticed that the bookmarks actually does load after the window is displayed (which led to the discovery of bug 172941). But the toolbar buttons are loaded before.
This type of thing can create obnoxious problems under systems running X due to the way X draws windows to begin with, and I just think it's kind of cheesy to load a window without having the widgets ready for it. Just my $0.02
blake, you said this might be interesting to invesigate. hyatt said probably not worth it. Confirming but this bug may still be marked wontfix.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: blaker → hyatt
Component: General → Toolbars
Taking QA Contact
QA Contact: asa → bugzilla
Assignee: hyatt → nobody
QA Contact: bugzilla → toolbars
Target Milestone: Future → ---
Time-to-useful-window nets out the same. I think we're generally fast enough that this wouldn't make an user-perceivable difference.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.