Topic: how does set time out work? (Page 1 of 1) Pages that link to <a href="https://ozoneasylum.com/backlink?for=27991" title="Pages that link to Topic: how does set time out work? (Page 1 of 1)" rel="nofollow" >Topic: how does set time out work? <span class="small">(Page 1 of 1)</span>\

 
knight
Neurotic (0) Inmate
Newly admitted

From:
Insane since: May 2006

posted posted 05-25-2006 12:25

Hi, I'm designing a site that is going to have an application feel to it, and to do that i wrote transitions such as fade in and fade out. Unfortunetaly I can get it to work if i use setTimeout to specific time intervals, ie after fade out after 1.5 seconds fade in, but I would like not to have to do this. I am pulling html from another page using a get request that is working, that is my _Ajax.getHTMLFrom

I know it's not commented verry well but the problem is in the first function _transition.fadeInTo. The other functions do work! I thought that when you used setTimeout it would spawn a new thread therefore i could just loop untill it was done however the browser frezes. so it is skiping the transition.fade call why???? I've been banging my head on the wall for a long time! THANKS!

code:
_transition = {};
_transition.fadeIsDone = true;
//public functions
_transition.fadeInTo = function(page,fadeObjectId) {
	info = _Ajax.getHMLFrom(page);
	_transition.fade(true,fadeObjectId);
//	while(!_transition.fadeIsDone) ;//wait();
	_transition.fadeTarget.innerHTML = info;
	_transition.fade(false,fadeObjectId);
//	while(!_transition.fadeIsDone);
}
_transition.fade = function(mode,fadeObjectId) {
	_transition.fadeIsDone = false;
	_transition.fadeTarget = document.getElementById(fadeObjectId);
	switch(mode) {
		case true:
			window.setTimeout("_transition._fade(true,100)",50); break;
		case false:
			window.setTimeout("_transition._fade(false,0)",50); break;
		default:
	}
	
}
//private functions
//mode can be true, false, or TOGGLE
_transition._fade = function(mode,opacity) {
	var fadeTarget = _transition.fadeTarget;
	switch(mode) {
		case true:
		  fadeTarget.style.filter = "alpha(opacity="+opacity+")";
		  opacity-=10; 
		  if(opacity > 0)
		   	window.setTimeout("_transition._fade(true,"+opacity+")",500); //call func again
		  else
			  _transition.fadeIsDone = true;
		break;
		case false:
		 	fadeTarget.style.filter = "alpha(opacity="+opacity+")";
			opacity+=10; 
			if(opacity < 100)
				window.setTimeout("_transition._fade(false,"+opacity+")",500);
			else
				_transition.fadeIsDone = true;
		break;
		case "TOGGLE": break;
		default:
			alert("Will not fade with mode "+mode);
	}
	
}



(Edited by knight on 05-25-2006 12:48)

_Mauro
Maniac (V) Inmate

From:
Insane since: Jul 2005

posted posted 05-30-2006 10:21

Timing. The concept of spawning a new thread is somehow "correct", although these aren't real threads.
But, since this concept is correct, the new thread runs as a separate branch of your application.

So, as soon as the first fade is called with true as the first param, the second call is made with false as the firs param.
What you have is a concurrency issue: both calls to fade run almost simultaneously.

You're better off, and this comes straight from the Doc, using a unique timer for all visual effects.
A unique thread of some sort which handles a "queue" of animated objects at any given time, and processes them.

Try poking at Doc's sources, or p01's, or mines for such a global, simple timer (for instance www.beyondwonderland.com => javascript pong)

Tyberius Prime
Maniac (V) Mad Scientist with Finglongers

From: Germany
Insane since: Sep 2001

posted posted 05-30-2006 12:59

Or have a look at http://script.aculo.us - a neat little library that saves tons of time on such problems.

liorean
Bipolar (III) Inmate

From: Umeå, Sweden
Insane since: Sep 2004

posted posted 05-30-2006 19:46

To understand how timers and events work in script, there's a few things you need to understand:
- All to me known ECMAScript engines are single threaded.
- ECMAScript doesn't have any constructs for threading nor thread safety for objects.
- The script engines executes "blocks of code", from start to finish, in their entirety.
- The script engines are "fed" these blocks of code from the host environment (browser usually) when they should be run. Thus, when parsing an HTML file, the host will send scripts to the scripting engine as it's finished parsing/downloading them, and the script engine simply runs the block of code, from start to end, when the host tells it to.
- To implement timers and events, the host environments use a scheduler and an event queue. The scheduler feeds the script engine with blocks of code gotten from this event queue. If more than one block of code is placed in this queue at the same time, the scheduler will give the blocks to the script engine for execution in the order they were placed in the queue.


This is all about-ish. There is more happening below the surface, we have many types of events that are internal to the host, the host may have priority balancing schedulers etc.

The reason setTimeout and setInterval are not part of the ECMAScript specification is just this - the timer events are strongly bound to the host environment, and have to be handled by the host.

--
var Liorean = {
abode: "http://web-graphics.com/",
profile: "http://codingforums.com/member.php?u=5798"};

_Mauro
Maniac (V) Inmate

From:
Insane since: Jul 2005

posted posted 05-30-2006 19:51

Oooohh.. interesting liorean. Thanks for sharing.
Just a mere statement on my side: when you get to render really high res stuff in real time, the timer precision becomes - incredibly - important.
But in js it's alright for simple effects, wether specified or not it is a required construct for many simple applications.

liorean
Bipolar (III) Inmate

From: Umeå, Sweden
Insane since: Sep 2004

posted posted 05-31-2006 05:06

Well, JavaScript isn't really made for graphics manipulation anyways, even less animation. It doesn't have integer types and doesn't have real arrays for pixel manipulations; it doesn't have any APIs specifically geared towards graphics, be that vector or pixel (except for recent additions or non-browser hosts anyways); it doesn't have reliable timers (Win9x your best timer resolution is 55 ms, WinNT it's 10 ms for uniprocessor/unicore/non-hyperthreaded systems and between 10 and 16 ms for multiprocessor/multicore/hyperthreaded systems), it's unreliably scheduled because it depends on the browser host environment, it's low priority and thus gets hit by context switching fairly often, the only timer method that could be considered reliable is the busy wait loop, and if you have more than one timer running all bets are off on the timing - moz is especially bad at scheduling multiple timers but at least you can rely on it firing the timer events in the right order.

Most of these problems are getting addressed, but it's still very far from being the best tool for the job.

--
var Liorean = {
abode: "http://liorean.web-graphics.com/",
profile: "http://codingforums.com/member.php?u=5798"};

_Mauro
Maniac (V) Inmate

From:
Insane since: Jul 2005

posted posted 05-31-2006 07:37

It all depends on what you think is best. In terms of being easilly usable and good learning material,
js has established a reputation. In terms of pure performances and accuracy, well, it's scripting, and it's cross-platform,
can't really blame it's shortcomings.



Post Reply
 
Your User Name:
Your Password:
Login Options:
 
Your Text:
Loading...
Options:


« BackwardsOnwards »

Show Forum Drop Down Menu