Phubar Baz

I've been experiencing Wirth's law firsthand lately. Wirth's law basically states that "Software is getting slower more rapidly than hardware becomes faster". This is no place more apparent than the antivirus programs we are all forced to run on our computers these days. I have a pretty good development machine with dual core processors and lots of memory. Yet I constantly find my machine bogged down taking way too long to do things. Especially in Visual Studio. It gets very frustrating when you're trying to get some work done. <whisper>Don't tell anyone, but sometimes I turn off my antivirus so I can get my work done on time.</whisper>

So have the terrorists really won? Here we are using half of our computing power to protect our computers against attacks from a bunch of shortsighted jackasses who think it's funny to write viruses. Like most terrorists they don't realize that they are also hurting themselves. Unless the people who write viruses don't protect their own machine from other people's viruses.

It reminds me of the old addage from Benjamin Frankin. "They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety". Replace liberty with productivity. Do we really need to much computing power reserved for protecting ourselves from viruses? Should Visual Studio be optimized so that it doesn't use so many system resources? Probably a little of both. But no one seems to care about optimizing their code any more. It's all about pushing out new features, not making things run faster.

 It's OK though because computers keep getting faster, right? I think Wirth's law is winning over Moore's law.

I am working on a Javascript app (CloudGraph) that uses HTML5 canvas and JQuery. I'm using ExplorerCanvas to support canvas in IE. I recently came across an interesting problem.

What I was trying to do is restore the user's settings when the page is loaded by reading some information from a cookie that I set the last time the user accessed the application. One of these settings is the size of the canvas. I decided that the best place to do this would be when the document is ready using JQuery $(document).ready().

This worked fine in browsers that natively support the canvas element. But in IE it kept getting errors the first time I would hit the page. It seemed that the excanvas element wasn't initialized yet because I was getting null reference and unknown properties errors. If I refreshed the page the errors went away but the resized canvas wasn't drawing on the entire area of the canvas. It was like the clipping rectangle was still set to the default canvas size.

I found that the canvas element when using excanvas has a div child element which is where the actual drawing takes place. When I changed the width and height of the canvas element in document.ready it didn't change the width and height of the child div. Initially my solution was to also change the div element when changing the canvas element and that worked.

But then I realized that having to refresh the page every time I started the app in IE really sucked. That wouldn't be acceptable for users. Since it seemed like the canvas wasn't getting initialized before I was trying to use it I decided to try to initialize my app at a different time. I figured the next best place was in the onload event. Sure enough, moving my initialization to onload fixed all of the problems.

So, it looks like the canvas shouldn't be manipulated until the onload event when using ExplorerCanvas. There might be ways to do it when the document is ready; I found some posts on initializing excanvas manually. But for me waiting until onload worked just fine.

I was working on my online mathematical graphing application, CloudGraph, and trying to make it work in IE. The app uses the HTML5 canvas element to draw graphs. Since IE doesn't support canvas yet I use ExplorerCanvas to provide that support for IE. However, it seems that when using excanvas, if you try to moveTo or drawTo a point that is not finite it loses it's mind and stops drawing anything else after that. I had no such problems in Firefox or Chrome so it took me awhile to figure out what was going on.

Next I discovered that I needed a way to check if a variable was NaN or Inifinity or any other non-finite value so I could avoid calling moveTo() in that case. I started writing a long if statement, then I thought there has to be a better way. Sure enough there was. There just happens to be an isFinite() function built into Javascript just for this purpose. Who knew! It works great.

Another difference I discovered with excanvas is that you must specify a starting point using a moveTo() when beginning a drawing path. Again, Chrome and Firefox are a lot more forgiving in this area so it took me a while to figure out why my lines weren't drawing. But, all is happy now and I'm a little wiser to the ways of the canvas.