Another jobless day

Another day passes, few phone calls yesterday from recruiters but I have not had very much luck with them so I won't get my hopes up.  At this point willing to relocate to just about anywhere to get a job. Wife insists that it's not the economy it's that I'm just lazy and haven't applied my self enough to the job hunt. Me being the quiet mousey type i just sit there and say nothing, I've learned that there's no point in arguing with her, she will keep going until she feels like she has won no matter how long it takes. But still, we're scraping by thanks to the grace of god and as long as that's happening we're a step above a lot of people in this day in age.

Anyways, did a bit more work last night on the canvas engine. Seems like Firebug has changed since I've lasted worked with the profile in the console. It no longer lists all the functions that are called like the old version. The old version would even list what classes were accessed, how often, and how much time it took. But alas I will have to just make due with it, just seems like their development progress took a step back. I have the mini map scrolling properly across the mm buffer, just need to get it updating the main map area fluidly.

Fluid updating of the map .... I've seen other's try this with DHTML and run into problems.  After you have optimized the draw portions of your map-renderer you then need a way to interact with it. Though I do try to avoid global variables for the obvious problems they can cause I've implemented a global boolean variable called notDrawing. This actually should be in the drawing class itself and it will be placed there later when I restructure it.

At the beginning of any event function that will do any rendering to the map the variable 'notDrawing' is set to false. When the calculations and rendering is complete then notDrawing is set to true. This allows you to very simply check the renderer .... 

if (notDrawing)

{

drawDetails(obj, x, y, tx, ty)

}

Very simple, but what is the point you may ask! Ok in order to make the mini map and the large main map move fluid they have to be redrawn as fast as the browser will allow. What you want to avoid though is over sending these draw calls as it will cause a slowdown instead and could lead to the browser being locked up. Even a short lockup of the browser will frustrate users and cause them to leave. 

Some other ways to optimize your JavaScript code... Avoid using EVAL, eval is bad as it forces a delay in your script and causes the browser to call it's parsing program. Other places where you use eval and might not even not it ... widows.setTimeout, or windows.setInterval. It has been common practice for years and i see this mistake in tutorials all the time where they do something like ... windows.setInterval="myFunction();". This is just like an eval statement and forces the browser to call it's parser routine. Instead remove the quotes and the parenthesis so it looks like .... windows.setInterval=myFunction;.

Another way to optimize your JavaScript code is to use VAR. In JavaScript you do not have to declare your variables, but by doing so it becomes a global, and as stated previously use of global's is bad. This is one of the primary problems that people run into when using JS Scripts from multiple sources, the fact that the variables conflict. I've seen some scripts use super long variable names to avoid this, which is ok i guess but seems a bit pointless. Just predeclare all your variables that you use with a VAR statement instead. That limits their scope to inside the {} brackets and I'm pretty sure it limits it to inside the .js script file as well, though i would need to do some testing first to be totally positive on that. 

Ok, time to start wandering around Raleigh dropping off resumes to the local web business's. I was told by a recruiter that this looks desperate ... but then again he drives a Ferrari so I'm pretty sure that he hasn't tried to find a job in quite some time, especially in this economy.