Forum libero

/*
> 		 *	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
> 		 */