On 5/21/14, May 21, 4:28 AM, Werner Lehmann wrote:
Did you try to lower the priority of your thread(s)? Also, I the suggestion to
wait a few frames, e.g. on the AnimationTimer, made a lot of sense to me. This
will of course slow down total startup time but there is a better chance of
having a complete splash screen.
Java/Thread Priorities/Linux - maybe not what you expect
<http://stackoverflow.com/questions/1662185/do-linux-jvms-actually-implement-thread-priorities>.
One of the tasks of the User Event Thread is to schedule/queue repaints, which
then happen on the Render thread. During startup - there is serious contention
for the user event thread, as it is used to initialize the world (which
includes your application). This is the same time when hotspot is waking up and
looking for something to optimize.
I am also wondering if there could be some kind of trigger to know when the
splash has hit the screen? Maybe SplashScreen.layoutChildren could spawn a
worker thread (or use runLater) to initialize the rest of the application.
One trick that I have used in the past - write your app to start up as if it is
only going to show the splash screen - and then create a worker thread that
delays a second or two before starting to build the rest of the app. This
slight delay can often help with the perceived startup speed as it gets
something on the screen faster.
Werner
On 21.05.2014 09:43, Mike Hearn wrote:
if there was a way to make the render thread higher priority than the
rest, that might also work
--
David Hill <david.h...@oracle.com>
Java Embedded Development
"A specification that will not fit on one page of 8.5x11 inch paper cannot be
understood."
-- Mark Ardis
