[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Follow-up on splash-screen questions

The splash screen also provides a progress bar and a place to display updating text.  In the old launcher this was actually implemented using a whole other instance of eclipse.exe running in a separate process.

Your example splash is using Swing, which I don't know very much about.  What does this mean when SWT will later be used to do all the UI?  This must work on all platforms and some have restrictions about which threads are allowed to do UI (carbon on the mac in particular must be the main thread).

Using SWT standalone when it was going to be loaded later through the OSGi framework introduces problems around the class loaders.  Which is why we didn't up trying to use SWT before it was loaded by OSGi.

The times reported in the bug were all done in XP on my laptop, which is a thinkpad T40.  The hard drive is a bottle-neck on this machine although there are certainly slower machines out there,
Note in comment #17, the "Time to Main", this is the time it takes to get to Main.main.  Nearly 6.5s of that 7781 ms is attributed initial eclipse.exe and to the Java VM starting (I don't recall which VM I was using, but it was started without any particular options).  The majority of the remaining 1.3s can be attributed to 1) Scanning the plugins directory to find the swt plugin and  2) extracting the native libraries out of the swt jar and putting them someplace on disk.  Any time taken by swt itself to actually display the screen would be small compared to these 2 items (though I don't have any numbers for this part).


Thomas Hallgren <thomas@xxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

02/13/2007 12:37 PM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

[equinox-dev] Follow-up on splash-screen questions

As a side-track on https://bugs.eclipse.org/bugs/show_bug.cgi?id=173742
I raised the question why the splash-screen is not handled completely by
Java. I'd like to continue that discussion here.

Andrew Niefer wrote:

> Thomas, the splash screen work was about more than simply displaying a graphic.
>  We wanted to use SWT widgets in the splash screen, otherwise we would have
> just stayed with the old splash story (which is separate from this discussion
> about startup.jar).  See
> http://wiki.eclipse.org/index.php/Equinox_Launcher_Plan
> http://wiki.eclipse.org/index.php/Splash_Screen_Improvements
> and bug 161569 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=161569> for details of the investigations.

I thought the initial splash screen was a graphical image only. I
realize that it gets more complicated when you need to pass a native
handle to SWT classes booted at a later time. Using pure Java for the
splash would probably rule out the use of SWT widgets.

> Time-to-splash was a major consideration.  On a cold machine (just turned on,
> no disk cache) the old splash method took around 6 seconds.  Showing a graphic
> in java would have been about the same.  For a properly setup eclipse using JNI
> to start the vm, the new launchre takes about 400ms on a cold start. (50ms on a
> warm start).

My reaction was to Pascals statement that Java is too damn slow for a
splash. I've tried various things on different machines, including
cold-start and clearmem.exe. I never get times anywhere near the 7781ms
reported for the "Funky Classloader" in comment #17. So question is, how
much of that time can be contributed to the use of SWT?

Kind Regards,
Thomas Hallgren

equinox-dev mailing list