 |
Author |
Topic: millis() and draw()/loop() (Read 829 times) |
|
benelek
 
 
|
millis() and draw()/loop()
« on: Jul 17th, 2003, 10:21am » |
|
this one might sit on the border of intention and bug... when using draw() mode instead of loop(), millis() doesn't seem to be updating.
|
|
|
|
|
arielm
|
Re: millis() and draw()/loop()
« Reply #1 on: Jul 17th, 2003, 10:59am » |
|
it's because draw() is executed only once (i.e. it's not looping)...
|
Ariel Malka | www.chronotext.org
|
|
|
benelek
|
Re: millis() and draw()/loop()
« Reply #2 on: Jul 17th, 2003, 11:07am » |
|
ay, which is why it might be intentional. but it's still useful to have millis() working. for example, when using threading. so maybe i should have posted in suggestions 
|
|
|
|
|
arielm
|
Re: millis() and draw()/loop()
« Reply #3 on: Jul 17th, 2003, 12:40pm » |
|
but... what kind of threading stuff _ that is not doable within loop() _ do you have in mind?
|
Ariel Malka | www.chronotext.org
|
|
|
benelek
|
Re: millis() and draw()/loop()
« Reply #4 on: Jul 17th, 2003, 12:57pm » |
|
hehe, yes anything you can do with draw() you can do with loop()... but it's a little redundant and wasteful if you don't need loop().
alrighty, here's a small sketch which is moving in the direction of time-allocation-management with a huge number of simultaneous threads... in it, a thread does some large arbitrary task, and uses millis() to calculate on each run, how long its delay() should be. this way, your whole computer is not slowed to a near-blue-screen-experience when increasingly large tasks are at hand.
Code://this is a sketch for automatic self-adjusting of threads' speeds.
//note that it will not work if draw() is used instead of loop(),
//because of limmitations on the use of millis().
//bnlk.
class threader implements Runnable {
int floorTime=5;
int delayTime=floorTime;
threader() {
}
public void run() {
while(true) {
long startMillis=max(1,millis());
//do some task:
for(int i=0; i<1000; i++) {
fill((int)random(255),0,0);
rect(random(100),random(100),random(100,200),random(100,200));
}
long finishMillis=max(2,millis());
delayTime=max(int(finishMillis-startMillis)+5,floorTime);
//println("...~ " + delayTime + " ~...");
delay(delayTime);
repaint();
}
}
}
threader object1;
Thread wrapper;
void setup() {
size(200,200);
noBackground();
}
boolean f=true;
void loop() {
if(f) {
object1=new threader();
wrapper=new Thread(object1);
wrapper.start();
f=false;
}
} |
|
|
|
|
|
|
arielm
|
Re: millis() and draw()/loop()
« Reply #5 on: Jul 17th, 2003, 1:27pm » |
|
sorry not to run your example, my machine just can't take the risk of crashing for now 
but let me reformulate my question: why do you need threads at all in processing, instead of having a smart "run()" dispatcher within loop?
|
Ariel Malka | www.chronotext.org
|
|
|
benelek
|
Re: millis() and draw()/loop()
« Reply #6 on: Jul 17th, 2003, 1:39pm » |
|
threading makes for more efficient use of processing power (p5 power?), and also allows for concurrent working structures. for instance, in that web-crawling app that was being discussed a day or so ago: being able to start lil' "children" threads that can run concurrently off into their growing families of links. using a complex web of object-orientation in the current structure of loop() within p5, this could be done, but it would end up feeling more like a hack than expanding explorative structure (to me).
also, threading opens up some new avenues in design. using threading, you can operate on simultaneous time-structures without having to do as much in the way of calculation/simulation. in a way, using real time-structures feels more honest.
any thoughts on these concepts would be appreciated.
|
|
|
|
|
arielm
|
Re: millis() and draw()/loop()
« Reply #7 on: Jul 17th, 2003, 2:12pm » |
|
well, i neved really used threads yet, but yes, it seems to me that they could be useful for network-related stuff (when you spend most of your time waiting, and you don't want to "block"...)
on the other hand, if there's in java an event-mechanism that ressembles javascript's onload(), then i guess it could be possible not to use threads...
concerning "simultaneous time structures", i guess there is a subtle balance between the overkill aspects of threading and the times when it's really needed.
i mean, you can "easily" manage a very big and complex set of objects interacting together, with a combination of loop() and events...
the problems (and the solutions that threading can give) may start when the execution loop of one single object among the whole is starting to take too much time...
any advanced java threading user to enlight us?
|
Ariel Malka | www.chronotext.org
|
|
|
toxi
|
Re: millis() and draw()/loop()
« Reply #8 on: Jul 17th, 2003, 4:37pm » |
|
first to the problem of millis(). the function's parameters are only updated when bagel starts a new frame. but i too think millis() should *always* stay updated by using System.currentTimeMillis() instead, very true. also note though, that in java under windows the resolution of the system clock is only ~10ms.
re: threads - of course it's possible to create serial solutions to parallel processes without any external support for threading, but that's not the question. benelek is right in saying that threads often (not always) use the system resources better and more elegant than a classic single mainloop programm structure as you suggested. java is by default a multi-threading environment and mainly because of this also so successful for all sorts of networking applications. every thread has a defined priority and important threads can interrupt threads with lower priority. e.g. the java garbage collector is an example of a constantly running thread of low priority and mainly runs when the system is idle. the concept of threading has not so much to do with event models as with multitasking. for instance in any multitasking environment, you've got a process scheduler running on the lowest level, which assigns the CPU dynamically and temporarily to concurrent running pieces of code (processes). java does the same only in its own context of the virtual machine.
because threads don't really know what else is going on around them and sometimes you have to avoid that several threads can modify the same data, java also gives you tools to "lock" access. (look up the "synchronized" modifier)
hth, toxi.
|
http://toxi.co.uk/
|
|
|
arielm
|
Re: millis() and draw()/loop()
« Reply #9 on: Jul 17th, 2003, 5:03pm » |
|
on Jul 17th, 2003, 4:37pm, toxi wrote:| of course it's possible to create serial solutions to parallel processes without any external support for threading, but that's not the question |
|
well, you never know , from a certain point of view, a processor is definitely a serial machine...
on Jul 17th, 2003, 4:37pm, toxi wrote:| the concept of threading has not so much to do with event models... |
|
i don't follow you on this one too... it depends what you call an "event": if a "notification" can be considered as an event, then i guess it's definitely related to threading...
and now to the punchline (lots of emoticons please), i have a strong intuition that most of the computer games on the market are not using threads (except for their networking / multi-user core, of course)...
boo!
|
Ariel Malka | www.chronotext.org
|
|
|
toxi
|
Re: millis() and draw()/loop()
« Reply #10 on: Jul 17th, 2003, 5:57pm » |
|
on Jul 17th, 2003, 5:03pm, arielm wrote:
well, you never know , from a certain point of view, a processor is definitely a serial machine... |
|
of course it is a serial machine, but that's why i wrote that's not the question. i know you're very much into playing with words...
Quote:| i don't follow you on this one too... it depends what you call an "event": if a "notification" can be considered as an event, then i guess it's definitely related to threading... |
|
for me there's a difference between a piece of code calling another function if a certain condition arises (your javascript onLoad example above) or a piece of code being interrrupted from external and then subsequently continues where it was paused.
Quote:| and now to the punchline (lots of emoticons please), i have a strong intuition that most of the computer games on the market are not using threads (except for their networking / multi-user core, of course)... |
|
you're right, but that'd be because multi-threading is not very practical for most games. however, often games do something similar to threading by implementing incremental algorithms. for instance pathfinding and other AI tasks can be very CPU intensive which when executed from start-end can bring down the overall framerate. so often these tasks are coded in a way they can be run in chunks (with a predicted max. execution time per step).
btw. what happened to the emoticons then
btw2. here's a (admittedly stupid) example to show that events and threads are quite something different:
Code:int[] testarray;
void setup() {
size(200,200);
testarray=new int[5];
}
void loop() {
int numItems=testarray.length;
println(numItems);
for(int i=0; i<numItems; i++) {
int dummy=testarray[i];
for(int j=0; j<1000000; j++) {
setPixel((int)random(width),(int)random(height),(int)random(0xffffff));
}
}
}
void mousePressed() {
int numItems=testarray.length-1;
testarray=new int[numItems];
} |
|
whenever you click the mouse the java system thread dispatches an event which will be trapped by the mousePressed() method. because the system thread has a higher priority than the one the main applet's loop() method is running in, you'll get an ArrayOutOfBounds exception shortly after you clicked the mouse. hope this makes sense as example...
|
http://toxi.co.uk/
|
|
|
arielm
|
Re: millis() and draw()/loop()
« Reply #11 on: Jul 17th, 2003, 6:35pm » |
|
okay, you convinced me (honest) about events and threads.
thanks for the code example... the following one is an extremely simplified test-case on the same subject:
Code:
int foo;
void setup()
{
foo = 1;
}
void mousePressed()
{
println("hello, it's mousePressed");
foo = 2;
}
void loop()
{
println("hello, it's loop");
for (int i = 0; i < 100000000; i++) // a long, long loop...
{
if (foo == 1)
{
}
else
{
println("toxi, you were right! emoticon fireworks here please...");
foo = 1;
}
}
}
|
|
now, if we wanted to avoid such a situation to arise, should we wrap the "long loop" into a "synchronized" block, or something similar?
(just in case you have the answer "off-hand"... otherwise, i can just check sun's site for more info about it!..)
10-x
|
Ariel Malka | www.chronotext.org
|
|
|
toxi
|
Re: millis() and draw()/loop()
« Reply #12 on: Jul 17th, 2003, 7:35pm » |
|
yeah synchronized code block is the way out of this. unfortunately this only works with objects and not "simple" datatypes (like int's etc.) as far as i know. but have a look at that:
Code:
TestObject foo;
// just a wrapper object for our value
class TestObject {
public int value;
}
void setup() {
foo = new TestObject();
foo.value=1;
}
void mousePressed()
{
println("hello, it's mousePressed");
synchronized (foo) {
foo.value = 2;
println("value changed to "+foo.value);
}
}
void loop() {
println("hello, it's loop");
synchronized (foo) {
for (int i = 0; i < 1000000000; i++) // a long, long loop...
{
if (foo.value != 1) {
println("oops... someone tried to change my value. not a chance! ;)");
foo.value = 1;
}
}
}
} |
|
so whenever you click the mouse now, the event callback is still executed straight away, but the thread then waits until the main loop's synchronized block is finished. only then the value is changed to 2.
also note this is not really an advisable coding practice as the system thread will not dispatch any new events until it returns from our mousePressed() method. so depending how much is going on in the loop() method, it can take a few seconds until the machine will register any more mouseclicks etc.
|
| « Last Edit: Jul 17th, 2003, 7:42pm by toxi » |
|
http://toxi.co.uk/
|
|
|
fry
|
Re: millis() and draw()/loop()
« Reply #13 on: Jul 17th, 2003, 8:13pm » |
|
a quick note.. millis() only updates once, and is an int (as opposed to the long returned by System.currentTimeMillis()). also, it starts from zero, which is the applet start time. this is in keeping with millis() being a useful value for keeping track of an animation, etc., or how time has elapsed during your applet. by implementing it this way, we 1) avoid having to do the int/long conversion, and 2) avoid needing to always subtract the 'start time' of the applet as is common when using System.currentTimeMillis(). both are good for beginnerrs. more advanced kids like y'all can use System.currentTimeMillis().
although, maybe we should add a millis2() (can anyone think of a better, but still short, name?) that is the same as System.currentTimeMillis(), but without all the typing (similar to System.out.println -> println). suggestions welcome.
[am also moving this thread over to suggestions]
|
|
|
|
|
toxi
|
Re: millis() and draw()/loop()
« Reply #14 on: Jul 17th, 2003, 8:20pm » |
|
ben why can't we change the current millis() implentation to something like this:
public int millis() {
return (int) (System.currentTimeMillis() - millisOffset);
}
this will always return up-to-date values and keep all the other advantages you mentioned. no?
|
http://toxi.co.uk/
|
|
|
|
