Splash Screen Improvements

Overview

Improving the launcher is one plan item (bug 154088) for Eclipse 3.3. One aspect of this is the splash screen. Currently the splash screen is handled natively by the launcher in a separate process. Being able to handle the splash screen from java would simplify the launcher code and make it easier to add functionality without bothering the SWT team.

Terminology

We shall consider 3 "components" in this discussion:

1. The Launcher executable. Native C code, responsible for starting java and displaying the splash screen.
2. Startup.jar. Java Code, the entry point for starting eclipse. Creates a classloader for the EclipseStarter which starts the framework.
3. Framework. Loading & Starting bundles, running the application.

Problem Description

The splash screen must be displayed early. For large products with thousands of bundles, the framework could take noticeable time to start up. This means the splash screen should be first shown before starting the framework, ie either in the Launcher or in the startup.jar.

Current Implementation

The Launcher starts java and runs the startup.jar. The startup.jar execs a new instance of the launcher which displays the splash screen. The Framework communicates with this splash process by writing to its standard input stream.

Initial Proposal

Startup.jar creates a special classloader containing the SWT fragment plus some splashscreen.jar. The splash screen is created on a new thread then the framework is created and started. SWT is later loaded in a Bundle classloader as normal. This means SWT is loaded twice in 2 different classloaders. The splash classloader and thread are thrown away when the splash screen is finished.

Problems:

• This is effectively 2 Display threads in one process (splash screen display, normal application display). Is this possible on all platforms? (MacOS, Motif, I don't think so)
• SWT classes loaded twice.

Variation

SWT becomes a special case in the framework so that the Splash Screen Classloader can be reused for the SWT Bundle. SWT classes are then only loaded once.

The splash screen thread becomes the UI thread. The Event loop must somehow move from the splash screen to the application.

Problems:

• The application must know not to create a new display, but to instead use the splash screen thread. This likely breaks other RCP applications.
• Special case for the SWT Bundle classloader.

Alternative Ideas

1. Splash screen is displayed by separate launcher process as a basic bitmap. This is displayed until the framework can load SWT and start the application, at which time:
   • Given the handle of the splash window/shell can SWT somehow draw into the other process' display ?
   • Given the coordinates of the basic splash screen, the application draws its own splash screen on top and tears down the old one. How noticeable would this transition be ?
2. Current launcher functionality is expanded to display bitmaps within the splashscreen. Bitmaps are streamed across from java.
3. Do nothing, things stay as they are.