Closed Bug 65425 Opened 24 years ago Closed 23 years ago

[BeOS] Splash not implemented.

Categories

(Core :: XUL, defect, P2)

x86
BeOS
defect

Tracking

()

VERIFIED FIXED
mozilla1.0

People

(Reporter: toyoshim, Assigned: cls)

Details

Attachments

(2 files)

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
Target Milestone: --- → mozilla1.0
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
Closed: 23 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.
v
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: