rails-devel

[Rails-devel] Splash Screen

[Frederick W. <fre...@go...>]

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

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

Re: [Rails-devel] Splash Screen

[Frederick W. <fre...@go...>]

Stefan:

> However are you sure that the the thread separation cannot create issues?

It's indeed quite a challenge to ensure that concurrent threads work
as expected under various situations. Therefore, when implementing the
splash screen, I refrained from any optimizations that were not
clearly without risks. The key is the following thread dependency:

- The splash thread (ProgressVisualizer inner class) will never cause
any issue as it is only considering the splash screen visualization of
what it has been notified.

- The init thread (non-EDT) creates/inits the classes (frames/panels).
Following swing's "realization" thread rule by the letter, I've put
any post-realization create/init logic (most often: pack()) of these
classes into an invokeLater. The same applies when finalizing the
initialization. There, the init Thread completely pauses until EDT is
through and issues setVisible / toFront within the EDT afterwards
(this is all done by invokeAndWait).

So as a result, the dependencies between init thread and EDT are drawn
very clearly and, by design, are very robust.

What I cannot exclude for 100% is that there is still some UI
component code (in some ? extends JFrame) that tries to access other
components when being run in the init thread. But I reduced the
likelihood of that being reviewing the existing code that is called
(transitively) during initialization.

So for the null pointer exception, please provide me the call stack
and I would follow up with an analysis.

My proposal for the splash screen would have been to include it into
1.7.0 and, if there are really reported issues, make it work for
1.7.x. I hope you understand I won't invest into reducing the scope of
this functionality, as it works fine for me and I would have been
willing to follow up on analyzing reported issues.

But it would also be a very valid option to exclude the functionality
from 1.7.0 (meaning forking 1.7.0 from before the splash screen
commits) and making more experiences with this for the weeks until
1.8.0.

My personal opinion is that for any feature I have developed in the
last months bugs could still be reported when releasing, the
probability for this to happen being only somewhat higher for the
docking framework and the game init refactoring.

So it's on you or the rest of rails-devel to decide...

-- Frederick

Re: [Rails-devel] Splash Screen

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

Frederick:
thanks for your explanations: Concurrency for me is still something that 
is a pretty demanding task (unless it is simple parallel processing). 
And I am neither an expert on Swing nor on the UI classes of Rails.

So basically you move out game setup into a non-EDT thread and then only 
have the required calls via SwingUtilities back to the EDT? And so it is 
not so easy to simply have one running before the other for testing 
purposes as there is more interleaving going on.

Still allow me one question to get a better understanding:
In which thread are those objects created that link to the rails core 
classes? Examples are GUITile, GUIHex and all Field elements?
For those you have to ensure that the Rails components are initialized 
before the UI equivalents/observers.

Sorry for not been able to provide the StackTrace of the Null pointer 
exception during initialization. As mentioned before it occurred at the 
first run after I have installed the Sun JRE/JDK in parallel, so I 
thought there was something wrong in the setup/classpath. I cannot even 
remember if the exception occurred inside a Rails class.
However it disappeared as I did test a game load instead starting a new 
game and then I was never been able to reproduce it.

So my proposal is take the risk and release all things quickly as it 
seems to me that you have taken care of most of the potential issues 
already.

But maybe there are other opinions and I would be glad to have more 
people have already tested the new setup already.

Stefan


On 02/18/2012 06:43 PM, Frederick Weld wrote:
> Stefan:
>
>> However are you sure that the the thread separation cannot create issues?
>
> It's indeed quite a challenge to ensure that concurrent threads work
> as expected under various situations. Therefore, when implementing the
> splash screen, I refrained from any optimizations that were not
> clearly without risks. The key is the following thread dependency:
>
> - The splash thread (ProgressVisualizer inner class) will never cause
> any issue as it is only considering the splash screen visualization of
> what it has been notified.
>
> - The init thread (non-EDT) creates/inits the classes (frames/panels).
> Following swing's "realization" thread rule by the letter, I've put
> any post-realization create/init logic (most often: pack()) of these
> classes into an invokeLater. The same applies when finalizing the
> initialization. There, the init Thread completely pauses until EDT is
> through and issues setVisible / toFront within the EDT afterwards
> (this is all done by invokeAndWait).
>
> So as a result, the dependencies between init thread and EDT are drawn
> very clearly and, by design, are very robust.
>
> What I cannot exclude for 100% is that there is still some UI
> component code (in some ? extends JFrame) that tries to access other
> components when being run in the init thread. But I reduced the
> likelihood of that being reviewing the existing code that is called
> (transitively) during initialization.
>
> So for the null pointer exception, please provide me the call stack
> and I would follow up with an analysis.
>
> My proposal for the splash screen would have been to include it into
> 1.7.0 and, if there are really reported issues, make it work for
> 1.7.x. I hope you understand I won't invest into reducing the scope of
> this functionality, as it works fine for me and I would have been
> willing to follow up on analyzing reported issues.
>
> But it would also be a very valid option to exclude the functionality
> from 1.7.0 (meaning forking 1.7.0 from before the splash screen
> commits) and making more experiences with this for the weeks until
> 1.8.0.
>
> My personal opinion is that for any feature I have developed in the
> last months bugs could still be reported when releasing, the
> probability for this to happen being only somewhat higher for the
> docking framework and the game init refactoring.
>
> So it's on you or the rest of rails-devel to decide...
>
> -- 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

Re: [Rails-devel] Splash Screen

[Frederick W. <fre...@go...>]

Stefan:
Thanks for wanting to get into the details of what has been done - I'm
also feeling more comfortable if the four-eye principle is applied for
such critical change.

Core rails objects are created in game.setup and game.load
respectively - both called within the init thread. GameUIManager's
gameUIInit is only called once this is done (as there is no
parallelization up that point in time - it's also called by the init
thread). This gameUIInit calls constructors and init method for all UI
components (eg., leading to the creation of GUITile and so on). By
this means, the game core layer is ensured to be fully available
before the UI layer begins to be set up.

As a further explanation, there is really much more potential of
parallelization / speed-up, but I had opted against that because
ensuring correct ordering would have been cumbersome (synch-points) or
not reliable enough. So there is really not much "magic" in the
changes - just putting the (isolated) last steps of UI component
initialization into a separate thread (EDT) and continuing with the
next UI component in the meantime.

-- Frederick