Splash window is not implemented. (And I'm working now :D)
marking NEW, because, well, it's not a dup, and it seems a fair request ;)
Status: UNCONFIRMED → NEW
Ever confirmed: true
I move implementation of BApplication from nsAppShell to nsAppRunner. Because splash window is appeared before construction of nsAppShell. And I added splash bitmap, and application icon to apprunner-beos.rsrc. nsNativeAppSupportBeOS.cpp is a splash window implementation for BeOS. It's a new file. And we need to change Makefile.in
changed priority to P2, and severity to major :)
Severity: normal → major
Priority: -- → P2
Is the splash supposed to pause Mozilla's startup for a couple of seconds? It definatly takes a few seconds longer to startup with the patch.
I'm going to have to defer to the more experienced BeOS developers on this one. Like Wade, I'm noticing about a 15-18 second delay when loading with the splash screen. Also, was it necessary to move the actual BApplication code from nsAppShell.cpp to nsAppRunner.cpp?
Thanks for reports, Wade and Chris. About the movement of BApplicaion, it's necessary for the same reason as the BCursor problem. Without BApplication object, we can not communicate with app_server, and can not create any other Application Kit's objects. For splash, we must create BWindow object, so we have to create BApplicaion here. (On the time we create splash, libwidget_beos.so have't been loaded.) About the delay, I can not find out difference between with splash and without splash in my environment. Anyway I will look into this delay problem. If you can, please try my private build too. http://www.toyoshima-house.net/bezilla/mozilla-0.7-20010118.zip BTW official 0.7 binary, and Wade's binary contain unnecessary files, I think. chrome/comm/, chrome/embed, and so on, these directories are replaced with comm.jar, embed.jar, ... So binaries don't need these directories. If you remove these, the binary save 2 or 3 Mbytes in size.
I had some tests on debug build. Following data is the result. First numbers are the time of the first nsWindow::ShowMenuBar() called. Second numbers are the time main() start. Last numbers are the differences of the two values, or the time required for launching bezilla. I tested five times on each situation. <<current cvs version>> 980185362.797 - 980185326.353 = 36.444 980185472.671 - 980185437.885 = 34.786 980185567.774 - 980185532.638 = 35.136 980185649.812 - 980185615.412 = 34.400 980185742.971 - 980185707.991 = 34.980 <<with new apprunner-beos.rsrc>> 980185917.010 - 980185881.216 = 35.794 980186032.751 - 980185998.279 = 34.472 980186125.332 - 980186083.929 = 41.403 980186225.880 - 980186191.199 = 34.681 980186314.927 - 980186280.558 = 34.369 <<with the move of BApplication impl.>> 980187380.352 - 980187345.847 = 34.505 980187694.705 - 980187660.008 = 34.697 980187779.283 - 980187745.088 = 34.195 980187861.007 - 980187826.800 = 34.207 980187958.560 - 980187923.516 = 35.044 << with full implementation of splash>> 980188281.717 - 980188244.981 = 36.736 980188374.231 - 980188339.549 = 34.682 980188489.880 - 980188454.858 = 35.022 980188571.084 - 980188536.432 = 34.652 980188657.327 - 980188622.694 = 34.633
I think this patch is ok to checkin, because it is well tested with recent builds. the arougthopher's build on BeBits and my 0.9.2 build on mozilla.org has this patch applied and both is working well. Also, we need to move BApplication out of widget, in order to enable Galeon-style project(as I guess), and this patch does it. I tested to apply the attachment 23170 [details] on the latest build and it still able to patch correctly. I don't think this patch will affect other platform. So please give us r= and check in. Thanks in advance.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Ok, I'll take your word for it. The delay is still noticable when bringing up the splash screen. It started off at about 12 secs but seems to get quicker with each test. It's down to about 8 secs now. Anyway, the patch has been checked in.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.