HTML and CSS Reference
In-Depth Information
At this point, the tabs on the right fill up with lots of useful information. The first three—Watch Expressions,
Call Stack, and Scope Variables—are generally used the most.
Watch Expressions, which are empty by default, is the spot where you can add expressions to be evaluated in
the current scope where the browser is stopped. If the value of a specific variable is important to figuring what's
happening, you can add it here for easy viewing. You can also add arbitrary expressions, such as calculations.
Click the little plus button on the tab header, and enter the expression. Because the expression is evaluated in
the current context, you can use the local variable and the
this
object in the expression. Mousing over a watch
and pressing the minus sign removes it. For complex values, such as objects and arrays, you can click the little
arrow to open the details of the watched element.
The second tab, Call Stack, shows where in the chain of function calls you are currently. Often the problem
you debug isn't related to the code that causes the error but rather to the code that called it with invalid para-
meters. Clicking any of the other methods in the call stack shifts the code view to the spot of the method call.
If, by some misfortune you debug code that has been minimized, you can click the helpful Prettyprint button
on the bottom of the window. It's represented by a pair of curly braces. This can format any code in the code
window in a sensible way, making it easier to figure out what's occurring.
The last tab, Scope Variables, is like an automatic set of watch variables that shows you all the variables
defined in the current scope. Because many times you'll be concerned with the values of variables local to the
current method, it saves you the step to add a watch. Unlike watched expressions, however, you can actually
change the value of variables by clicking their values, which is handy if you need to change any values to try
different values out.
Just looking at your code at one specific line won't generally give you the information you need to debug
your game. You most likely want to step through your program in small controlled steps to track down exactly
where things are going afoul. To do this, you can use the small row of controls above the tabs on the right (see
Figure 7-14
)
.
Figure 7-14:
The script debugging controls.
The first button either pauses the script execution or restarts it if it is paused. If you've hit a breakpoint script,
execution will already be paused and clicking this button restarts it until the next breakpoint is hit. The next
button, Step Over the Next Function Call, is used to step line-by-line over your code. The debugger won't jump
any deeper into the stack but just executes all the code on a single line and then goes to the next one. The next
two buttons, Step into the Next Function Call and Step out of Current Function Call, enable you greater control
over how you progress through the code. If you want to step further down the stack, press the first one; if you
want to execute code until the current method returns, press the second. Finally, after you figure out what's hap-
pening, you can press the last button to toggle enabling and disabling all break points. Turning off breakpoints
is useful when you need to play your game for a moment to achieve certain conditions. You can then press this
button to toggle breakpoints back on to stop your code exactly where you need to be.
Profiling and Optimizing Your Code
HTML5 Canvas performance on the desktop has reached a point on most browsers in which you don't need to
pay too much attention to performance when you create a simple 2-D game. (This was not the case in 2010,
