pythoncard-users

[Pythoncard-users] Loading/splash screens

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

Hmmm...a chicken-and-egg problem...and a bit OT.

Some of my PythonCard apps run on fairly old hardware, with the result 
that the Python interpreter/runtime takes a while to start up with 
nothing apparently happening as far as the user is concerned. A loading 
splash screen would be good, but if this was summoned from 
Python/PythonCard/wxPython then it would happen too late.

Has anybody done any brainstorming on this and come up with a solution, 
or is anyone aware of one? I remember hearing on a podcast recently that 
  a future version of Java will load some basic functionality ahead of 
the JVM to allow splash screens to be drawn early on, when an 
application is run that requires the JVM to be loaded. I don't think 
Python allows anything like this, though I'd love to be proved wrong.

-- 
XXXXXXXXXXX

Re: [Pythoncard-users] Loading/splash screens

[Alex T. <al...@tw...>]

XXXXXXXXXXX wrote:

> Hmmm...a chicken-and-egg problem...and a bit OT.
>
> Some of my PythonCard apps run on fairly old hardware, with the result 
> that the Python interpreter/runtime takes a while to start up with 
> nothing apparently happening as far as the user is concerned. A 
> loading splash screen would be good, but if this was summoned from 
> Python/PythonCard/wxPython then it would happen too late.
>
> Has anybody done any brainstorming on this and come up with a 
> solution, or is anyone aware of one? I remember hearing on a podcast 
> recently that  a future version of Java will load some basic 
> functionality ahead of the JVM to allow splash screens to be drawn 
> early on, when an application is run that requires the JVM to be 
> loaded. I don't think Python allows anything like this, though I'd 
> love to be proved wrong.
>

I don't know if this is a solution or not .... but I've always noticed 
that the wxPython demo gets the splashscreen up there pretty quickly, 
and then the real window follows a while later. But that may be just 
because it deliberately holds the splashscreen up on screen for two 
seconds, rather than because it is going through the rest of its 
initialization. In any case, it may be worth your while trying what it 
does .....

1. the demo.pyw is very small - all it does is "import Main" then call 
Main.main()
This means that there is a "compiled" version of the majority of the 
program (Main.pyc) which may save some time.

2. The app is very small (load and display a bitmap, and schedule a call 
to the real app for two seconds later).
So (with suitable arrangement of the code), you can delay most of your 
app's initialization to after the splash screen is visible.

That may or may not help - depends how much time is just getting the 
base interpreter up and going.

If that doesn't help, you might consider a lightweight "main" program 
(not in Python) which simply displays the splashscreen and then runs the 
real app ... there are certainly shareware apps that do this, and a 
thorough search may well find a freeware one (for Windows - probably 
also for Mac or Linux but I don't know)

See http://www.intrepidmouse.com/products/ssm/index.asp for a shareware 
example.

-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.9/216 - Release Date: 29/12/2005

Re: [Pythoncard-users] Loading/splash screens

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

On 30/12/05 01:22, Alex Tweedly wrote:
> I don't know if this is a solution or not .... but I've always noticed 
> that the wxPython demo gets the splashscreen up there pretty quickly, 
> and then the real window follows a while later.
<snip>

I'd forgotten about the demo...wxPython (and wx in general) is still a 
bit of a blind spot for me. But the splashscreen part looks pretty 
straightforward.

> That may or may not help - depends how much time is just getting the 
> base interpreter up and going.

Quite a large proportion of the loading by the look of it. The demo 
splashscreen takes an age to appear on my cold-booted NT box (Pentium 3 
700MHz, 640MB RAM, 5400rpm ATA/100 drive...not an unusual spec. for 
where I have to distribute my application).

> If that doesn't help, you might consider a lightweight "main" program 
> (not in Python) which simply displays the splashscreen and then runs the 
> real app ... there are certainly shareware apps that do this, and a 
> thorough search may well find a freeware one (for Windows - probably 
> also for Mac or Linux but I don't know)
> 
> See http://www.intrepidmouse.com/products/ssm/index.asp for a shareware 
> example.

I'm an old school C programmer and had considered creating a "stub" that 
launches a py2exe/McMillan installer-created Python executable. It was a 
bit of a last resort though ;-)

Thanks for the pointers
-- 
XXXXXXXXXXX

[Pythoncard-users] Re: Loading/splash screens

[Thomas H. <th...@py...>]

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX writes:

> On 30/12/05 01:22, Alex Tweedly wrote:
>> I don't know if this is a solution or not .... but I've always
>> noticed that the wxPython demo gets the splashscreen up there pretty
>> quickly, and then the real window follows a while later.
> <snip>
>
> I'd forgotten about the demo...wxPython (and wx in general) is still a
> bit of a blind spot for me. But the splashscreen part looks pretty
> straightforward.
>
>> That may or may not help - depends how much time is just getting the
>> base interpreter up and going.
>
> Quite a large proportion of the loading by the look of it. The demo
> splashscreen takes an age to appear on my cold-booted NT box (Pentium
> 3 700MHz, 640MB RAM, 5400rpm ATA/100 drive...not an unusual spec. for
> where I have to distribute my application).

I have a 800MHz P3 box with 512 MB with XP SP2 for testing.

Times are for py2exe created applications.
An application with a custom GUI based on ctypes takes far less than a
second to show the window.  A wxPython app takes about 3 seconds.
If this is too slow for you, or your system is slower, see below.

>> If that doesn't help, you might consider a lightweight "main"
>> program (not in Python) which simply displays the splashscreen and
>> then runs the real app ... there are certainly shareware apps that
>> do this, and a thorough search may well find a freeware one (for
>> Windows - probably also for Mac or Linux but I don't know)
>> See http://www.intrepidmouse.com/products/ssm/index.asp for a
>> shareware example.
>
> I'm an old school C programmer and had considered creating a "stub"
> that launches a py2exe/McMillan installer-created Python
> executable. It was a bit of a last resort though ;-)

For a C programmer it should not be a problem to extend the py2exe
sources to include a dialog resource, then call CreateDialog somewhere
to create the spash screen.  The C code could DestroyWindow the dialog
just before starting the Python main script, or you could even expose
a DestroySplashscreen function to Python which would then destroy the
dialog after the GUI is initialized.

Thomas

Re: [Pythoncard-users] Re: Loading/splash screens

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

On 30/12/05 12:34, Thomas Heller wrote:

> I have a 800MHz P3 box with 512 MB with XP SP2 for testing.
> 
> Times are for py2exe created applications.
> An application with a custom GUI based on ctypes takes far less than a
> second to show the window.  A wxPython app takes about 3 seconds.
> If this is too slow for you, or your system is slower, see below.

My hardware might be on the slow side. After rebooting, my P3 takes 
about 12 seconds to get the wxPython demo splashscreen and about 15 
seconds to start up my PythonCard application from the .py file. My 
McMillan'd executable of the same app takes 10 seconds.

A 2.8Ghz Celeron laptop with 4200rpm drive and (apparently) crappy 
motherboard architecture gives me approximately the same results. This 
is all testing after a reboot each time - if I repeat the run without 
reboot then disk caching, etc. must kick in because the times drop to 
2-3 seconds.

OK, I admit it, I'm impatient :-) Unfortunately I'm also dealing with 
users who, if there's no on-screen feedback, will start double-clicking 
again and, hey presto, before you know it there are four copies of the 
application started.

> For a C programmer it should not be a problem to extend the py2exe
> sources to include a dialog resource, then call CreateDialog somewhere
> to create the spash screen.  The C code could DestroyWindow the dialog
> just before starting the Python main script, or you could even expose
> a DestroySplashscreen function to Python which would then destroy the
> dialog after the GUI is initialized.

Ooo...sounds interesting. Thank you - I'll take a look.

-- 
XXXXXXXXXXX

Re: [Pythoncard-users] Loading/splash screens

[Kevin A. <al...@se...>]

On Dec 29, 2005, at 4:03 PM, XXXXXXXXXXX wrote:

> Hmmm...a chicken-and-egg problem...and a bit OT.
>
> Some of my PythonCard apps run on fairly old hardware, with the result 
> that the Python interpreter/runtime takes a while to start up with 
> nothing apparently happening as far as the user is concerned. A 
> loading splash screen would be good, but if this was summoned from 
> Python/PythonCard/wxPython then it would happen too late.
>
> Has anybody done any brainstorming on this and come up with a 
> solution, or is anyone aware of one? I remember hearing on a podcast 
> recently that  a future version of Java will load some basic 
> functionality ahead of the JVM to allow splash screens to be drawn 
> early on, when an application is run that requires the JVM to be 
> loaded. I don't think Python allows anything like this, though I'd 
> love to be proved wrong.
>
> -- 
> XXXXXXXXXXX

I would go ahead and ask on wxPython-users as I suspect this is 
something one of the other developers has dealt with in the past. You 
could add some calls to time various spots in the startup process, but 
disk caching, first time compilation of to .pyc files, etc. will mean 
you'll get different results each time.

In the end my guess is that you might have to do something that will 
make your code less portable such as using ctypes or win32 to load 
something small right at the beginning of your program to display an 
image or message on screen and then wait for the rest of the app to 
load.

ka

Re: [Pythoncard-users] Loading/splash screens

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

On 30/12/05 05:49, Kevin Altis wrote:
> I would go ahead and ask on wxPython-users as I suspect this is 
> something one of the other developers has dealt with in the past. You 
> could add some calls to time various spots in the startup process, but 
> disk caching, first time compilation of to .pyc files, etc. will mean 
> you'll get different results each time.

...and just to confuse things a bit more, I presume that when I use 
McMillan to create an executable, then any work I've done delaying 
imports until they're actually needed (rather than sticking everything 
at the start) is probably negated to some degree as the whole 
application becomes one executable and a lot of DLLs.

Mind you, it seems to be the interpreter that's taking the time to load, 
so...

> In the end my guess is that you might have to do something that will 
> make your code less portable such as using ctypes or win32 to load 
> something small right at the beginning of your program to display an 
> image or message on screen and then wait for the rest of the app to load.

I like ctypes (I don't have to throw away all the old C DLLs I've 
created over the years :-)) but that will also require the Python 
interpreter to be up-and-running. So it's looking more and more like 
I'll need to roll my own C "stub" to create the splashscreen and somehow 
disappear once the Python interpreter is loaded. Yikes.

Thanks for the suggestions....I need to do some more research!

-- 
XXXXXXXXXXX