Thread: [Visualpython-users] Running in a browser

Occasionally users of VPython have expressed interest in displaying
VPython animations in a browser. Unfortunately, Python doesn't run
in a browser, but something related is in the works.

David Scherer, the creator of VPython, and I are working on making it
possible for VPython-ish programs to run in a browser window. Recently
many browsers (all the major ones other than Internet Explorer)
include WebGL, a graphics library similar to the OpenGL library used
by VPython. JavaScript programs can drive WebGL, in a browser.

Here is an example of a JavaScript+WebGL version of the VPython demo
program doublependulum:

    http://tinyurl.com/684xldd

This JavaScript program looks very similar to the original program and
would look even more similar were it not for the fact that among the
features not yet implemented is the frame object. If the frame object
were implemented, this JavaScript program could have been created
almost entirely by using an automatic converter program I've just
written (in Python). In the absence of this project, the
doublependulum program would include a ton of extremely arcane
JavaScript code, just as VPython is supported by a ton of arcane C++
code.

What's the point of this? Well, for example, you may know
there's an ebook version of the intro physics textbook "Matter &
Interactions" written by Ruth Chabay and me. Both Wiley and we want
eventually to add interactive features such as animations, and it
seems likely that would/should take place in a browser, in particular
because (as you'll see in the demo mentioned above) one of the
strengths of this approach is that there can be text and other
standard browser elements on the web page in which the animation is
embedded. Ruth and I would like to be able to use our suite of demo
programs, and write additional ones, without killing ourselves in
minutiae.

We do NOT think that this is a replacement for VPython, and for
student use in intro physics. Python is a much more mature and cleaner
language than JavaScript, and Python has the blessing of computer
scientists, so for both technical and political reasons Python is a
far better choice for introducing computational physics than is
JavaScript.

Scherer solved two unsolvable problems to get to the point we've
reached after a few weeks of work. Unlike Python, JavaScript does not
support "operator overloading", in which you can for example change
the meaning of the operator "+" so that 2+3 is 5 but vectors v1+v2
have their individual components added. Nevertheless, by a clever
approach Scherer has made it possible to add and subtract vectors, and
multiply by scalars: v+v, v-v, s*v, v*s.

The second unsolvable problem is that a JavaScript+WebGL program has
to be "event-driven", with the program divided into pieces to be
called by the web page manager. This requirement means that a
straight-forward orbit program will run through an entire loop before
the web page ever gets updated, so you only see the final state, not
the animation, and if the loop is an infinite loop you never will see
anything. Scherer found a tool named "streamline" that will take a
non-event-driven JavaScript program and automatically convert it to an
event-driven JavaScript program. The only burden on the programmer is
that instead of including, say, rate(100) in a loop (to iterate only
100 times per second), you have to include rate(100,_), where the "_"
is a signal to the streamline engine where it can break the loop
contents into a separate routine that is called 100 times per second.
(We intend to change the signal "_" to something meaningful, like
"wait").

You can also in this environment write true event-driven programs, but
we feel strongly that this style of programming is not where the
novice should start.

Stay tuned!

Bruce

P.S. At the moment, the tinyurl above will work on Chrome on Windows
and Mac and Linux, and on the WebKit version of Safari on the Mac (a free
download that enhances Safari). It should also work on Firefox but
doesn't at the moment, though it has in various past versions of the
project so I expect it will eventually work again.

P.P.S. The attentive reader will have noticed that I didn't reveal the
name of this project. That's because we haven't yet thought up one
that David, Ruth, and I are happy with. Suggestions welcome!

Due to some major restructuring that's going on, the example of a
JavaScript+WebGL version of the VPython demo program doublependulum is
no longer working at http://tinyurl.com/684xldd. Instead, use this
link:

     http://tinyurl.com/633acxv

Bruce Sherwood

Does anybody has some experience with multithreading and VPython?
Standard examples are silent, the tutorial just mentions that the 
rendering thread is separate

I did some simple tests (with the threading module without any locks, 
some "planets" wandering concurrently on the screen), no serious 
problems, but if somebody tried some torture example, and noticed 
something, I would be grateful to know.

I noticed something I cannot interpret. Two objects move, and two loops 
running in different threads execute time.sleep(slp). Nothing wrong. I 
replace the sleeping by rate(1.0/slp), and the second thread waits until 
the first terminates. Why?

Maestro Bruce?

All the best.

Jerzy Karczmarczuk
Caen, France.

I don't feel terribly competent concerning the threading aspects of
VPython and have no ready explanation of what you've observed about
sleep and rate. However, I have reason to expect that generally
speaking, using the threading module should work okay, as you've
found, because I believe that's all within the Python machinery. In
contrast, the rendering thread that runs about 30 times per second
shuts down Python completely while rendering is in progress.

Bruce Sherwood

On Tue, Nov 1, 2011 at 5:21 PM, Jerzy Karczmarczuk
<jer...@un...> wrote:
> Does anybody has some experience with multithreading and VPython?
> Standard examples are silent, the tutorial just mentions that the
> rendering thread is separate
>
> I did some simple tests (with the threading module without any locks,
> some "planets" wandering concurrently on the screen), no serious
> problems, but if somebody tried some torture example, and noticed
> something, I would be grateful to know.
>
> I noticed something I cannot interpret. Two objects move, and two loops
> running in different threads execute time.sleep(slp). Nothing wrong. I
> replace the sleeping by rate(1.0/slp), and the second thread waits until
> the first terminates. Why?
>
> Maestro Bruce?
>
> All the best.
>
> Jerzy Karczmarczuk
> Caen, France.
>
>
> ------------------------------------------------------------------------------
> RSA&#174; Conference 2012
> Save $700 by Nov 18
> Register now&#33;
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

I noticed that the use of rate(...) introduces some conflicts to 
threads. Bruce Sherwood answers:
> I don't feel terribly competent concerning the threading aspects of
> VPython and have no ready explanation of what you've observed about
> sleep and rate. However, I have reason to expect that generally
> speaking, using the threading module should work okay, as you've
> found, because I believe that's all within the Python machinery. In
> contrast, the rendering thread that runs about 30 times per second
> shuts down Python completely while rendering is in progress.
Thank you.
This last point is not a problem. Python itself is a dinosaur, with its 
GIL (Global Interpreter Lock), and it is not very suitable to make 
something like an operating system, or a general multiprocessed 
simulation program within. But threads work well. This DOES NOT mean 
that they must work correctly with binary modules, such as cvisual, and 
it seems that we have such a case here.

The rendering doesn't show any pathologies - as far as my VERY 
INCOMPLETE tests show - but the function rate(...) seems buggy (from 
this perspective!). This is the simplified skeleton of my program, which 
moves the objects obj through the space

rr=RLock()
def move(args...):
    ...
    for i in seq():
         #          rr.acquire()
         # rate(1.0/slp)
         #          rr.release()
         obj.pos=newxyz()
         obj.trail.append(pos=obj.pos)
         time.sleep(slp)
...
t1=Thread(target=move, ...)
t2=Thread(target=move, ...) # with different params, geom and timing.
t1.start()
t2.start()
# =====================

This program works without any problems.
1. Comment time.sleep, uncomment rate(). Result: the thread t1 runs 
until completion, then the second particle starts moving. (Here the 
RLock is not used.) You can imagine my surprise...

2. Place rate() within a critical section, by uncommenting acquire() and 
release() of the reentrant lock, which can be released only by its 
owner. Ha! Try to guess what happens... (It is in principle possible, 
but not obvious.)

The behaviour is funny: the two particles move concurrently, but 
synchronized! Despite the differences in timing (the parameter slp), now 
in every thread exactly one step is executed before the relinquishing of 
control. Notice that I didn't put in the critical section the 
instructions which deal with the rendering!

Lesson to learn: if you want an *asynchronous parallelism*, even without 
race conditions or other conflicts, DON'T USE rate(), since - it seems 
(I looked up the file rate.cpp) - it uses one, global timer in a thread 
of its own, and that's it.

My proposal for the future versions of VPython, with (probably) rather 
feeble priority: either remove rate() altogether, and demand that the 
users use the timing procedures in the kernel of Python + the time 
module, etc.,

or revise thoroughly the threading aspects of cvisual.

==
Of course, it is quite possible that I am saying rubbish, it was just 
one hour of testing...

+++

A secondary comment on a slightly different subject. Bruce Sherwood says 
that the rendering thread works at a speed of about 30 frames/second. 
But VPython offers now the stereo vision, with the possibility to use 
shutter glasses.
I suspect that at this speed, it might be insufficiently comfortable for 
everybody... Perhaps it can be boosted and/or parameterized?...

Thank you very much, and my best regards.

Jerzy Karczmarczuk
Caen, France

PS. The complete version of the program if you want to check it, is here:
http://users.info.unicaen.fr/~karczma/TEACH/VPY/thr_test0.py

One point is that rate and sleep have different purposes.

rate is trying to make sure that each iteration of the loop takes a time slp.  So to get the same effect from sleep, you would need to call time.sleep(slp-delta), where delta is the amount of time taken by the instructions in the rest of the loop.




On Nov 2, 2011, at 7:35 AM, Jerzy Karczmarczuk wrote:

> I noticed that the use of rate(...) introduces some conflicts to threads. Bruce Sherwood answers:
>> I don't feel terribly competent concerning the threading aspects of
>> VPython and have no ready explanation of what you've observed about
>> sleep and rate. However, I have reason to expect that generally
>> speaking, using the threading module should work okay, as you've
>> found, because I believe that's all within the Python machinery. In
>> contrast, the rendering thread that runs about 30 times per second
>> shuts down Python completely while rendering is in progress.
> Thank you.
> This last point is not a problem. Python itself is a dinosaur, with its GIL (Global Interpreter Lock), and it is not very suitable to make something like an operating system, or a general multiprocessed simulation program within. But threads work well. This DOES NOT mean that they must work correctly with binary modules, such as cvisual, and it seems that we have such a case here.
> 
> The rendering doesn't show any pathologies - as far as my VERY INCOMPLETE tests show - but the function rate(...) seems buggy (from this perspective!). This is the simplified skeleton of my program, which moves the objects obj through the space
> 
> rr=RLock()
> def move(args...):
>    ...
>    for i in seq():
>         #          rr.acquire()
>         # rate(1.0/slp)
>         #          rr.release()
>         obj.pos=newxyz()
>         obj.trail.append(pos=obj.pos)
>         time.sleep(slp)
> ...
> t1=Thread(target=move, ...)
> t2=Thread(target=move, ...)  # with different params, geom and timing.
> t1.start()
> t2.start()
> # =====================
> 
> This program works without any problems.
> 1. Comment time.sleep, uncomment rate(). Result: the thread t1 runs until completion, then the second particle starts moving. (Here the RLock is not used.) You can imagine my surprise...
> 
> 2. Place rate() within a critical section, by uncommenting acquire() and release() of the reentrant lock, which can be released only by its owner. Ha! Try to guess what happens... (It is in principle possible, but not obvious.)
> 
> The behaviour is funny: the two particles move concurrently, but synchronized! Despite the differences in timing (the parameter slp), now in every thread exactly one step is executed before the relinquishing of control. Notice that I didn't put in the critical section the instructions which deal with the rendering!
> 
> Lesson to learn: if you want an asynchronous parallelism, even without race conditions or other conflicts, DON'T USE rate(), since - it seems (I looked up the file rate.cpp) - it uses one, global timer in a thread of its own, and that's it.
> 
> My proposal for the future versions of VPython, with (probably) rather feeble priority: either remove rate() altogether, and demand that the users use the timing procedures in the kernel of Python + the time module, etc.,
> 
> or revise thoroughly the threading aspects of cvisual.
> 
> ==
> Of course, it is quite possible that I am saying rubbish, it was just one hour of testing... 
> 
> +++
> 
> A secondary comment on a slightly different subject. Bruce Sherwood says that the rendering thread works at a speed of about 30 frames/second. But VPython offers now the stereo vision, with the possibility to use shutter glasses.
> I suspect that at this speed, it might be insufficiently comfortable for everybody... Perhaps it can be boosted and/or parameterized?...
> 
> Thank you very much, and my best regards.
> 
> Jerzy Karczmarczuk
> Caen, France
> 
> PS. The complete version of the program if you want to check it, is here:
> http://users.info.unicaen.fr/~karczma/TEACH/VPY/thr_test0.py
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> RSA® Conference 2012
> Save $700 by Nov 18
> Register now!
> http://p.sf.net/sfu/rsa-sfdev2dev1_______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

James Mueller  :
> One point is that rate and sleep have different purposes.
>
> rate is trying to make sure that each iteration of the loop takes a 
> time slp.  So to get the same effect from sleep, you would need to 
> call time.sleep(slp-delta), where delta is the amount of time taken by 
> the instructions in the rest of the loop.
>
OK, but doesn't matter.
Some simple instructions in Python don't take much time. (And if the 
rendering thread is autonomous, it doesn't waste the time of the main 
process.
If in my cited program you eliminate all waiting, the process terminates 
before you are able to see any movement.

Who will need an incredibly fine tuning while programming in Python?

You may make some variants, if you wish, e.g. introduce into a loop a 
timing block which measures the time lapse /since its last call/, and 
wait until your "rate" condition is fulfilled.
Clumsy...

==
The problem is the thread safety. The sleep() call *is* a replacement 
for rate(), that's all I wanted to say.

Thank you for your reaction.
Best regards.

Jerzy Karczmarczuk

I'm not sure I follow all the issues here, but I do want to emphasize
as James Mueller points out that rate is NOT an equivalent of sleep.
Its purpose is to put an upper bound on the rate at which an animation
runs, so that on a very fast computer your animation doesn't run so
fast you can't see it.

Bruce Sherwood

On Wed, Nov 2, 2011 at 7:20 AM, Jerzy Karczmarczuk
<jer...@un...> wrote:
> James Mueller  :
>
> One point is that rate and sleep have different purposes.
> rate is trying to make sure that each iteration of the loop takes a time
> slp.  So to get the same effect from sleep, you would need to call
> time.sleep(slp-delta), where delta is the amount of time taken by the
> instructions in the rest of the loop.
>
> OK, but doesn't matter.
> Some simple instructions in Python don't take much time. (And if the
> rendering thread is autonomous, it doesn't waste the time of the main
> process.
> If in my cited program you eliminate all waiting, the process terminates
> before you are able to see any movement.
>
> Who will need an incredibly fine tuning while programming in Python?
>
> You may make some variants, if you wish, e.g. introduce into a loop a timing
> block which measures the time lapse since its last call, and wait until your
> "rate" condition is fulfilled.
> Clumsy...
>
> ==
> The problem is the thread safety. The sleep() call is a replacement for
> rate(), that's all I wanted to say.
>
> Thank you for your reaction.
> Best regards.
>
> Jerzy Karczmarczuk
>
>
> ------------------------------------------------------------------------------
> RSA&#174; Conference 2012
> Save $700 by Nov 18
> Register now&#33;
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>

Bruce Sherwood :
> I'm not sure I follow all the issues here, but I do want to emphasize
> as James Mueller points out that rate is NOT an equivalent of sleep.
> Its purpose is to put an upper bound on the rate (...)
Alright, no point in continuing. This is my last message on this subject.
I didn't say a single word about the purpose of rate()! You are right, 
but it doesn't change anything in my messages.

However, rate()*IS* more or less based on sleep(), and if you do not 
agree, look at the code : rate.cpp:

rate_timer::rate_timer() {
   origin = sclock();
   }
   void rate_timer::delay(double delay) {
   float t = delay - (sclock() - origin);
   if (t > 0.010) {
*threaded_sleep(t);*
   } else while (delay - (sclock() - origin) > 0);
   origin = sclock();
   };

It simply computes the sleep time according to the specification of rate.
I claimed ONLY that cvisual seems to use one shared timer, and it 
precludes the asynchronous animation. Moreover the last while loop 
suggests that for delays smaller than 0.01 sec, the handler simply 
enters an idle loop, doing nothing. This is not the most excellent 
solution, since it blocks /everything/ (only the OS preemption breaks 
this loop).

Perhaps J. Brandmayer could say something about the possibilities to 
rationalize this. (His name is cited as the author of the code.)

I suggested to use time.sleep() as a replacement, practically *it 
works*, and that's all.
I believe that the handling of events by VPython could be discussed, and 
perhaps modernized a bit as well, but another time.

Thank you, everybody. Over.

Jerzy Karczmarczuk
Caen, France