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

[Thomas Hallgren <thomas@xxxxxxx>]

Hi Andrew,

Andrew Niefer wrote:
> 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?
Not much I think. Swing is known to run just fine together with SWT. 
Eclipse already provides a bridge that enables Swing panels to run 
within a SWT control. I've written some apps with it and it works great 
for the most part. But I'm not advocating a switch. Eclipse is built on 
SWT so I think it is natural that the splash should be based on that too.

>  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).
>
> 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 have some questions regarding the native launcher and the differences 
in performance between the old and new. "Time to Main" with the old 
native launcher is measured at 6398ms. The new native launcher is 
claimed to have a splash up form cold start in 400ms! That's actually 
less then the difference between "Time to Main" and "Time to Splash" 
using the old launcher. What would be the cause of this dramatic 
difference to get to the main? And once in main, what is causing the 
dramatic difference in getting the splash up?

Another somewhat disappointing observation. I'm running both 3.3M4 and 
3.3M5 on my machine right now. I see virtually no difference at all in 
splash performance. Both seem to take around 2s after a clearmem. I 
actually perceive my "java -jar splash.jar" example as slightly faster! 
How can that be?

Seems we get radically different results. I'm not using anything 
scientific, just my eyes and a clock :-)

Kind Regards,
Thomas Hallgren