Forum libero

> http://anynowhere.com/personal/wirez/wirez.html

/*
		 *	overall context attributes:
		 *	these are coupled with the Src object to which this Wrc is linked
		 *
		 *	notes:
		 *
		 *	      - coupling is intentional for performance reasons; furthermore,
		 *	      - strokeStyle and lineWidth are presumed to be set by rendering code
		 *		just before the drawing method is called, as they never vary while
		 *		wireframe primitives are traced
		 *
		 *	about 'enumerateProgressively':
		 *
		 *	      - currently the 'parseHeightmap' function will sort terrain polygons
		 *		by re-mapping their indices from their vectorized sequence in a
		 *		quadrant's hMap array into a sequence (in the cMap array) where a
		 *		polygon has an always higher numeric index the closer it gets to
		 *		the camera's position, so that scanning the cMap array from index
		 *		zero to index <cMap.length - 1>, skipping void entries in-between,
		 *		will result in accessing polygons' data from the farthest to the
		 *		nearest polygon, allowing the painter's algorithm to take care of
		 *		covering the farthest polygons with the nearest ones; HOWEVER, the
		 *		solution works only if a <for ... in> loop in the javascript engine
		 *		will scan properties under numeric keys in numeric order and not in
		 *		the order they were entered into the cMap array; this is true for
		 *		three of the tested engines (of Chrome, Opera and IE) out of four,
		 *		the missing one being that of Firefox: as such, Firefox will need
		 *		an additional step after polygons from a quadrant's heightmaps are
		 *		recollected using 'parseHeightmap', a step which consists in making
		 *		a new "ordered" array (oMap) by scanning cMap in numeric order with
		 *		a regular <for> loop, adding entries to oMap as they're found, to
		 *		finally use oMap to drive polygons' tracement: as it occurs in one
		 *		step and linear time, it might still be much faster than a sort of
		 *		a totally unordered array by distance, but still, if the browser
		 *		doesn't need the extra step because its <for ... in> loops already
		 *		access the cMap array in the intended numeric order, it's better
		 *		save the time taken by creating a new object (oMap), which is the
		 *		default setting and doesn't work on Firefox: now, about detecting
		 *		this situation, setting enumerateProgressively to the result of...
		 *
		 *			(function () {
		 *
		 *				var n = 1;
		 *				var r = [];
		 *
		 *				r[1] = 0;
		 *				r[0] = 1;
		 *
		 *				for (var i in r) {
		 *
		 *					n = 2 * n + r[i];
		 *
		 *				}
		 *
		 *				return n == 5 ? true : false;
		 *
		 *			}) ();
		 *
		 *		couldn't correctly guess the behavior of a generic browser, since
		 *		even Firefox processed r[0] before r[1] in that case; I'm for now
		 *		assuming the behavior is unpredictable there, and activating that
		 *		flag according to browser detection
		 */