You can place the code within a jQuery callback to get started, but the spinner isn’t required when good coding is used.
With 25 I’ve turned this from taking 1.5 seconds to taking only 4 milliseconds, which is nearly well over 350 times faster.
The main thing that I did to improve on this is to remove the coords to string conversion, and remove as many global variables as possible.
I’ve also used objects to contain the x/y coords, which while they don’t provide much speed benefit, result in easier to read code.
function line_exists(lineFrom, lineTo, subdivided_output) {
var i,
from,
to,
sameStart,
sameEnd,
switchedStart,
switchedEnd;
for (i = 0; i < subdivided_output.length; i += 1) {
from = subdivided_output[i].from;
to = subdivided_output[i].to;
sameStart = (from.x === lineFrom.x && from.y === lineFrom.y);
sameEnd = (to.x === lineTo.x && to.y === lineTo.y);
switchedStart = (from.x === lineTo.x && from.y === lineTo.y);
switchedEnd = (to.x === lineFrom.x && to.y === lineFrom.y);
if (sameStart && sameEnd || switchedStart && switchedEnd) {
return true;
}
}
return false;
}
Another example of improvement in terms of performance is in the subdivide function. Before it was looping through all lines and then using modulus with skip:
for (ii = 0; ii < output.length; ii++) {
if([b]ii%skip==0[/b] && output[i] != output[ii] && line_exists(output[i],output[ii], subdivided_output)==false){
...
So with a skip of 4, that is similar to this:
0. ii % skip = 0 so use this
ii % skip = 1 so don’t use this
ii % skip = 2 so don’t use this
ii % skip = 3 so don’t use this
ii % skip = 0 so use this
ii % skip = 1 so don’t use this
ii % skip = 2 so don’t use this
ii % skip = 3 so don’t use this
ii % skip = 0 so use this
The updated code doesn’t need that check, because it just loops by the skip amount:
for (to = 0; to < output.length; to += skip) {
if (output[from] !== output[to] && !line_exists(output[from], output[to], subdivided_output)) {
...
So with a skip of 4, that is similar to this:
0. use this
4. use this
8. use this
The improved speed also means that most of your size constraints shouldn’t be required now.
The working code is up at http://jsfiddle.net/pmw57/kJVjR/2/
Put in sides of 25, or 40, and you’ll find that there is now an instantaneous response time.
Very Awesome! You’ve given me a lot to chew on. I’ll go through and review it until I understand all of it. I’ve been wanting to add sliders it sounds like with this information it will be practical.
To clarify, the “from =” is a completely different “from” than the one used in “.from” at the end.
One is a named variable, while the other is an object property.
Previously, push was being used to add items to the subdivided_output array:
Using the push method with only one item tends to be slower than other techniques, so to squeeze more performance out of this section, we can use the array length to add the item to the end of that array.
It’s also preferable to use [arrayItem] instead of new Array(arrayItem) too.
I also renamed the for loops to make it clear what they are referring to.
Which can also be done without the array notation, as:
sub_coord1=subdivided_output[iii].from.x + ...
Using [‘from’] or .from, those are not array variables. They are just ways to access object properties.
That line of code might be easier to understand if the variables are adjusted slightly, so that instead of using from/to to store the coord, we use start/end instead.
That way we would have code like this:
x and y are defined in the shape function. They used to be array items, such as:
points=new Array(x,y);
output.push(points);
which is the same as doing:
output[i] = [x, y];
however, storing them as array items results in needing to use [0] and [1] to access their values, and they are actually different types of values, so it makes better sense and is easier to read when we store and access them as x and y properties instead.