[GRASS-dev] splash screen image comes up too late [Re: Planning GRASS GIS 7.0.0RC2]

Moritz Lennert mlennert at club.worldonline.be
Mon Feb 9 07:36:13 PST 2015


On 09/02/15 16:19, Anna Petrášová wrote:
>
>
> On Mon, Feb 9, 2015 at 10:10 AM, Moritz Lennert
> <mlennert at club.worldonline.be <mailto:mlennert at club.worldonline.be>> wrote:
>
>     On 09/02/15 15:47, Martin Landa wrote:
>
>         Hi,
>
>         2015-02-09 15:32 GMT+01:00 Anna Petrášová <kratochanna at gmail.com
>         <mailto:kratochanna at gmail.com>>:
>
>             Perhaps we should go back  to the previous version. I would
>             suggest to move
>
>
>         agreed, done in r64527.
>
>             the GMFrame import after showing the splash screen (the diff
>             is for release
>             branch):
>
>
>         done in r64528.
>
>             as a result on my computer, the splash screen is showed
>             earlier. It probably
>             won't effect the problem Moritz has, but it's worth trying.
>             I also saw
>
>
>         Moritz, does it any effect for you?
>
>
>     Well, now I have the same problem of a temporarily empty splash
>     screen again which was solved with your previous modification. And
>     as mentioned I don't really see any difference in speed for the
>     arrival of that empty splash screen.
>
>     Am I really the only one who sees this empty rectangle as a splash
>     screen for a little moment before the image fills it ???
>
>
> I haven't noticed this on Windows and my Ubuntu laptop with any wxPython
> version.


Martin, you are on Debian as well, aren't you ? What is different in our 
setups that could explain this difference ?

>
> Would splash.Show() help when you put it before wx.Yield?

Neither splash.Show(), splash.Update(), or splash.Refresh() make any 
difference, here.

Martin's solution (creating first the splash screen as a separate class, 
is the only one that has worked for me so far, with the caveat that it 
slows down startup by +/- a second on my machine.

All of this is not dramatic except for the weird impression an empty 
splash screen gives.

AFAIU, the best solution is to separate splash creation and general GUI 
execution, and according to your info, Anna, forking seems the best 
solution for that if we want to avoid the speed penalty of Martin's 
solution.

But let's concentrate on the more important tasks to get GRASS7.0 out of 
the door.

Moritz


More information about the grass-dev mailing list