I was contacted by Paul Kienzle (sorry, no link), who is using this code for client-side rendering when other options (like canvas) are not available to him. He has made a number of optimizations which I hope he will be able to get up on GitHub, either in “master” or in a fork.

To give you an idea of Paul’s speed improvements, he’s seen original speeds of 1.8s for a 400×400 plot drop down to 0.25s. Amazing! However, it turns out that the actual decoding step performed by some browsers becomes the bottleneck. I would not have expected that.

This project uses my SVG path parser to fire events on a renderer as the path data is being parsed. The renderer uses the highest-order curves supported by a given target to plot whatever is being asked of it. For example, if a render target supports only moveto and lineto drawing primitives, the renderer will tesselate beziers thus adding support for those curves where they didn’t originally exist. It’s pretty rough, but I was able to render to DIVs, Flash, inline SVG, and VML, in some cases using pre-exising libraries for the actual renderering.

I had all sorts of plans for the code, but, alas, time isn’t alway cooperative. One area I thought would be interesting in which to experiment would be to convert the stroke of a path to a path itself. In this sense, JSDrawing could be used as an effects pipeline, allowing for ideas like stroking a stroke, in the spirit of Vector Effects..and the end result could be in turn SVG itself. Anyway, JSDrawing might prove to be interesting to some folks out there. You can find that bits at JSDrawing on GitHub.

Long time, no blog. I guess that’s the nature of tech interests and all that. However, I’ve been delightfully surprised to continue to receive emails over the years from people that have found bits and pieces of the site useful…even after begin dormant for almost 6 years!

In an effort to increase visibility of some of the more interesting code on KevLinDev and to make it easier for others to fork, branch, commit, etc., I plan to move bits and pieces to GitHub as time permits. And what better way to set priorities on what to move first than by basing my list on the gentle proddings of the emails I receive?

The first item to move to GitHub is my DigiMemo 692 DHW file format conversion utility which was discussed in Christmas Fun. This was one of those hey-wouldn’t-this-be-neat ideas where a few hours later I ended up with a utility to take my horrible handwriting and drawings and then convert them to SVG. Well, it’s years later and now that code has been reborn on GitHub and lives at the following URL:

DM2SVG

The script is quite simple and could easily be converted to other languages. One thing I always wanted to add was animation showing the drawings as they were digitized over time. So, for those of you in this very much of a niche use-case, enjoy!

P.S. Thanks go to David Yonge-Mallo for reminding me of this project. He has a nice blog post up that uses a variant of my code to generate Jarnal files.

Ideally, setTimeout could fire a function as if it were a method. That would make “this” inside the function’s body refer to the particular instance firing the function. That in turn would give us something to which we could attach state for each setTimeout invocation. Unfortunately, that’s not an option with today’s implementation of setTimeout, so we need a workaround.

In the past, I would enqueue the object containing my state, call setTimeout, and then dequeue the object in the timer handler. This gets a bit ugly since you have to maintain arrays (still somewhat globally) and it’s fairly easy to imagine a situation where two setTimeouts can interfere with one another if they share the same array. We get around these issues via a JavaScript closure.

The first important point is that setTimeout implementations allow the first parameter to be a function reference as opposed to a string. The second important point is that we can make a closure by creating a function literal. The closure allows our function literal to access variables that were in its scope when it was defined. To make this a bit clearer, let’s create a Person object that counts down at a regular interval.

function Person(name, count) {
    this.name = name;
    this.count = count;
}

Person.prototype.countDown = function() {
    var self = this;
    var process = function() {
        println(self.name + “: ” + self.count);

        self.count–;

        if (self.count > 0) {
            self.countDown();
        }
    }

    setTimeout(process, 500);
}

When the “process” function is called via setTimeout() “this” would refer to global instead of our Person instance. We create a “self” local variable as a sibling to the function literal. This makes “self” visible to the function literal’s body regardless of where it actually executes. This is one of the beauties of closures. We have effectively glued the active Person instance to the “process” function, so when it fires, it can access that instance.

To make sure we really have multiple contexts, we can test with something like the following:

function init() {
    var john = new Person(”John”, 3);

    john.countDown();

    // delay the other counter
    setTimeout(init2, 250);
}

function init2() {
    var sarah = new Person(”Sarah”, 5);

    sarah.countDown();
}

You can see a sample at:

/tutorials/javascript/inheritance/count-down.htm

Enjoy.

Liz and I moved back to Texas last week, so I had three days to ponder everything you can imagine as we drove through the Southwest in separate vehicles. (As an aside, it is amazingly beautiful from roughly Yuma to El Paso right now due to all the rain they’ve been getting. It’s a nice roadtrip this time of year.) Of course, I got to thinking about the Game of Life and an interesting article I read years ago about a very fast hardware approach to image convolutions. I’ve never been particularly happy with the speed of my SVG Life implementation, but, as is typical for many developers, I never really had the time to explore how to speed things up…until today. The good news is that with a minor tweak of my Bitmap object and an adaptation of the hardware technique, my implementation is about ten times faster. Even better, Opera and Firefox run about twice as fast as IE 6.

http://www.kevlindev.com/alife/life/life_2_0_bw.svg

And here’s the old version for reference:

 http://www.kevlindev.com/alife/life/life_bw.svg

The code is still in a little bit of a rough state right now, but I’m happy with the results. I’m pretty sure I could squeeze out a bit more speed, but I guess that will have to wait for another weekend…and hopefully before the next roadtrip.

Enjoy!

If you write HTML, CSS, and JavaScript then you should give Aptana a try. You can see the IDE in action with a number of screencasts we’ve put up on Aptana.tv. Oh, and this is all open source and free.

    http://www.jorendorff.com/articles/javascript/speed-test.html

“Yahoo! just announced YUI 0.11 (their JavaScript library) and after I applied a little pressure they decided to use a variation of your extend function as one of their three most fundamental methods in the library.”

Peter has a nice post comparing code written with “extend” in JS versus ports written in Java and Ruby. A comment at the bottom of that page announces the latest YUI release and includes some useful links related to the project.

Thanks for the heads-up Peter!

The idea is simple: for each set, add a unique tag to a hash for each item in that set. Then, walk the key/value pairs of the hash and perform a comparison on each value. The comparison determines the set operation you wish to perform.

We start with this first function that iterates over all elements in an “items” array (we’re assuming these values are strings for this sample). Each element value serves as a property name in the “tags” object. We simply append the value of “tag” to that property’s value.

function setTag(tags, items, tag) {
    for (var i = 0; i < items.length; i++) {
        var item = items[i];
        if (tags.hasOwnProperty(item)) {
            tags[item] += tag;
        } else {
            tags[item] = tag;
        }
    }
}

The next function is useful for many things; however, for this example, we use it to return all property names of an object whose values meet some specified criteria. We pass in a function to test each property value to determine if we want that property name in our result or not. This allows us to define all of our set operations very concisely and flexibly.

function filter(tags, matchFunction) {
    var result = [];

    for (var p in tags) {
        if (matchFunction(tags[p])) {
            result.push(p);
        }
    }

    return result;
}

That’s all we need to perform our set operations. So, let’s see what the intersection operation looks like.

function intersect(setA, setB) {
    var tags = {};

    setTag(tags, setA, “A”);
    setTag(tags, setB, “B”);

    return filter(
        tags,
        function(value) {
            return value == “AB”
        }
    );
}

We create an empty object to hold our tags for each set. We tag all items from set A with the letter “A” and likewise we tag set B items with the letter “B”. Finally, we return all property names from “tags” whose values equal “AB”. Only names that appear in both “A” and “B” will match this criteria which gives us an intersection.

A slightly more expanded set of operations (along with the code above) can be seen at http://www.kevlindev.com/utilities/sets/sets.svg. That file also includes some operations on 3 sets which may give insight into how this approach can be expanded beyond 2 sets.

It’s surprising how useful these rather simple functions can be. It all comes down to how you define the matchFunction used in the “filter” function.

A number of my samples use SMIL and, unfortunately, there appears to be no SMIL support in Firefox. I could resort to script to emulate SMIL; however, the irony is that I created many of those examples to explicitly avoid the use of script.

Another problem was with the use of em values in the dy attribute of <text> and <tspan> elements. Ems are useful in that they allow me to define leading independently of font size. Without them, I have to hard code the font-size. This is a bit annoying in cases where I want on-the-fly font-size changes (maybe for accessibility reasons, for example). I have to resort to DOM magic to update the attributes to match the new size and heaven forbid if I was using values like 1.25em.

I ran into an issue where large rectangles stopped firing mousemove events. ASV had a nice “feature” that let you define ridiculously large rectangles to get mouse events outside the browser’s window. I adopted this practice in a number of places, but Firefox didn’t like the values I was using. Fortunately, I was able to reduce the rectangle size and I started getting events again.

I haven’t done any performance comparisons, but it feels like ASV is fastest of the three in many cases. Firefox comes in second and Opera is the slowest. However, a few fairly CPU-intensive samples were noticably faster in Firefox which was good to see.

It’s really encouraging to see SVG expanding into new spaces. Lets just hope this support will continue to grow and to improve in these browsers and not go the way of ASV.