Topic: how does set time out work? (Page 1 of 1)

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!

_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)

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)

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

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"};

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.

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"};

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.