Reduce startup time by showing window before loading customized toolbars




16 years ago
11 years ago


(Reporter: djst, Unassigned)


Firefox Tracking Flags

(Not tracked)




16 years ago
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.

Comment 1

16 years ago
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.

Comment 2

16 years ago
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

Comment 3

16 years ago
blake, you said this might be interesting to invesigate. hyatt said probably not
worth it. Confirming but this bug may still be marked wontfix. 
Ever confirmed: true

Comment 4

16 years ago
-> toolbars
Assignee: blaker → hyatt
Component: General → Toolbars


16 years ago
Target Milestone: --- → After Firebird 1.0
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.
Last Resolved: 11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.