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
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
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
> 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
> about startup.jar). See
> 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
> 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
much of that time can be contributed to the use of SWT?
equinox-dev mailing list