Re: [Rails-devel] Splash Screen

[Stefan F. <ste...@we...>]

Frederick:
the splash screen looks awesome.

However are you sure that the the thread separation cannot
create issues? I had once during testing a Null pointer error message, 
however this was first time after I switched to test it using the sun 
jre, so I thought it was likely due to that. However I was not able to 
reproduce it in the following and it does not even occur after switching 
forth and back from openJdk.

So I suspect that this might have come from the thread separation. Have 
you tested if the two can truly run independently by running first 
thread A followed by thread B and vice versa?

I have to admit that I was surprised that you were able to create a 
clean separation given the current code, but you everything you did so 
far made it likely that you were able to achieve that.

Given the speed improvement I would prefer to either not including that 
in 1.7.0 or restrict it to two threads (one for the splash, another for 
game init and UI startup), until more testing has been done.

Could I ask you for the favor to bundle your commits for a new feature 
using git rebase --interactive? You have to be aware e.g. cherry-pick 
currently allows only selecting one commit and not a range of commits?
And it makes creating the release readme easier to have only one commit 
instead of 16.

Still it looks great!

Thanks,
Stefan


On 02/17/2012 06:32 PM, Frederick Weld wrote:
> Master now contains logic that is aimed at improving the user
> experience during game initialization (new/load). A major motivation
> for this is that loading a rails game on a docking layout takes close
> to 40 secs (on my old computer).
>
> Most important aspects are as follows:
>
> - Splash screen provides information about initialization progress
>       - no java.awt.SplashScreen but a custom one as it is only
> displayed after the choice in the game setup window
>       - can be turned of by an option in the Windows section
>
> - Windows become visible at once initialization is completed
>       - no more one-by-one popping up of the windows
>       - windows are already painted when becoming visible (important
> for the ORWindow with background maps - which were inited white
> before)
>
> - Moderate reduction of initialization time:
>       - class loading / window setup/wiring is done in a non-EDT thread
>       - painting triggered early and done concurrently by EDT
>       - third (minor) thread for visualization of initialization progress
>       - performance test (loading 1856 game with docking frames and
> background map):
>            - Time until all windows become operational (and background
> map is completely drawn):
>                - before: 38 secs
>                - now: 31 secs
>
> -- Frederick
>
> ------------------------------------------------------------------------------
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel