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