On systems where D3D pipeline is used its initialization may take significant fraction of startup time.
(on warm start it is up to 30% till applet.init() is called on my PC).
Refworkload tests shows it takes 180-200ms on my PC (see comments).

We knew that D3D had startup overhead when d3d support was added to JDK. There were efforts to reduce cost of d3d initialization and further reduction is likely to be complicated task. We should have another look though.

On other hand it does not seem that d3d initialization is CPU consuming. It seems to be mostly bound by necessity to communicate with OS and drivers.
So, perhaps it is possible to reduce total startup time by initializing D3D concurrently to other activities.

Some possible ideas (have not been prototyped/verified yet):
  a) change plugin to create embedded frame in parallel to processing cache data, initiating network downloads, etc.
  b) change d3d, to initialize minimum at first request and continue further init in the background. It must be finished before first draw to the screen
  c) change java launcher and awt, to start initializing d3d concurrently to VM initialization. Attach d3d initialization thread to VM later and use it as AWT's toolkit thread.

      In later case we may only launch this warm up thread under some circumstances (e.g. if it was explicitly requested). This is something to decide later on.