RSS

First off, Color Jack is a cool little tool, and fun to manipulate. It’s for anyone who’s ever wondered, “what colors would look good with this?”

Now, when I try it in Firefox is works fine. Just slide the points around and they do their thing. In Internet Explorer, the program runs with an agonizing slowness. You’d think that color sphere was comprised of 10,000 bump-mapped self-shadowing polygons. It gets about a frame a second. How can it possibly be that slow?

Wow! Very useful utility. Thank you.
The reason it is slow in IE, I would presume is simply that IE is awfully slow on javascript, and this thing seems to be implemented entirely in javascript. There is no flash involved here at all.

@Deoxy: Flash does do a lot better in IE than in Firefox, it just doesn’t make a whole lot of difference in some flashes. Try running an intense vector-based Flash movie in a full browser window to get a good test. Basically, if a movie slows down considerably in Firefox, try it in IE.

A good benchmark that I typically use is Flash Flash Revolution r2 — a web-based DDR simulator (r2 in particular because its requirements are ridiculously high and, more importantly, because it has a framerate counter). In Firefox, it sometimes manages 60 fps, but when arrows start coming on the screen it dips down to 45 fps, going as low as 30 fps in my tests. In IE it never dips below 50, even with a lot of arrows on the screen at once.

As a web developer who has done a lot of heavy, AJAX style javascript, I can tell you it’s because IE’s javascript engine is aginizingly slow. I’ve spent days trying to optimize code for IE that would run very fast in firefox. In many of my tests firefox would run as much as 10 times faster. IE7 does seem to be a little better then IE6 but it still doesn’t hold a candle to FF. I think the problem is in how IE manages the DOM and rerenders the page after adding/changing DOM elements. I’ve seen it peg out my processor for 5-10 seconds and consume hug amounts of memory to do things that happen in less then a second in FF.
I’ve done a little work with Flash and I don’t think it matters. Flash uses its own engine separate from javascript and it seems to work fine in both environments. This would change, of course, if you are doing a lot of Javascript-Flash communications within the page.

That’s a really neat resource. Runs fine in Safari for Mac, by the by. I’m an amateur at visual design, in the sense of actively doing a fair bit of web design at the hobbyist level. I’ve wanted something along these lines for quite a while.

Hey, the problem is the code is written in AFLAX for Internet Explorer. Whereas in Firefox it uses native canvas.

AFLAX slows down the process because it compiles flash via javascript… try using Firefox to speed it up. I really need to learn native flash! I’ve got some other projects that are going to need it soon as well.

Glad you like Sphere :) I would suggest using Kuler if you’re on Internet Explorer, however.

Years ago I did some work on this using, of all things, Visual Interdev, which showed me that IE registers a staggering number of event contingencies for each ID’d element on a page. ID an element and you’ll immediately get a shirtload of callbacks generated. These do indeed slow everything down to a manageable speed.

Whether this is relevant to the color picker tool issue (which is indeed a neat thing) I don’t know, but those javascripters who are seeing slow times on IE can get sometimes staggering performance gains by rescripting client-side dynamics to use array-based processing where appropriate and removing all the unneeded ID attributes from the HTML tags.

Just something I found by brute-force techniques and have tried and proved for myself. I don’t write javascript for a living, so there may be even cleverer ways to pull off the speed trick in the IE DOM.