Silverlight

[NickFitz]

Bit off topic but what I can't understand about jscript is the slow speed with which it manipulates images. OK, it's interpreted so you expect long scripts to be slow, but a single statement to move an image by a few pixels should take about the same time in any language, they would be using the same compiled dlls I'd have thought.

Modern implementations use Just-In-Time compilation to native code. IE9 even has a neat trick of interpreting code as the page is loading while handing off compilation to a second core, if available; the compilation process can then inject compiled code back into the interpreter process as it becomes available, meaning a function might run as interpreted code when called at the very top of the page but, if called again halfway down, run as compiled code. Once compilation has been completed, which will normally be by the time the page has finished loading, all subsequent execution in response to events or timers will run as native code. This is how they've managed to get IE's script performance back on a par with Chrome, Safari, Firefox, and Opera.

DOM manipulation can be a complex thing, depending on how you do it. If you move something about then it's possible that the browser has to reflow the entire page in order to determine which parts it needs to repaint. If the element is absolutely positioned relative to the document element it greatly reduces the amount of calculation the browser has to do for each frame.

The usual cause of jerky animation, though, is the assumption that an interval timer set to fire every 20ms will fire every 20ms, regular as clockwork. This isn't a valid assumption as the timer could be delayed for any number of reasons, whether it be an external process hogging CPU so the browser itself doesn't get the chance to trigger the timer event on time, to the browser itself being occupied with some long-running task like garbage collection. I did a lot of research into this at ClientOrg last year, although I was only testing on Chrome, Firefox, and Opera (I was working with SVG so IE wasn't relevant). This showed that Chrome was the most reliable, being bang on the millisecond about 99.5% of the time, whereas Firefox (3.6) was the worst, sometimes introducing delays of up to 300ms or so. As the interval timer won't try to fire all delayed events, this means that a 20ms interval timer running for 1 second might not even fire 50 times, but only 48; also, there might be several times when the spacing of the events is more like 30ms - 18ms - 12ms, giving three events in 60ms with the third being exactly 60ms from the start time, but none of the two intervening events firing on schedule. Opera is particularly prone to this, giving a kind of sawtooth effect to my charts of the results.

One way to fix this is to, on each tick, use the time since start time to determine the actual current proportion of the overall duration (as opposed to what it would be in an ideal world) and calculate the current offset based on that. So to move an absolutely-positioned element right by 200 pixels in two seconds, you'd do something like:

function moveThing(thingToMove) {
    var startX = 0,
        endX = 200,
        deltaX = endX - startX,
        duration = 2000,                 /* milliseconds */
        interval = 20,                   /* milliseconds */
        startTime = new Date().getTime(),
        timer;
    timer = setInterval(function() {
            var currentTime = new Date().getTime(),
                /* make sure we don't overshoot, even if the last tick is late */
                deltaT = Math.min(currentTime - startTime, duration),
                deltaD = deltaT / duration,
                deltaX = Math.floor(deltaD * deltaX);
            thingToMove.style.left = (startX + deltaX) + "px";
            if (deltaT == duration) {
                clearInterval(timer);
            }
        }, interval);
}

[d000hg]

One way to fix this is to, on each tick, use the time since start time to determine the actual current proportion of the overall duration (as opposed to what it would be in an ideal world) and calculate the current offset based on that.

Oh... I figured that was too obvious to suggest to a seasoned developer. But then I come from a game-development background, different low-level domain knowledge.

[xoggoth]

That may be a factor but with larger images the main problem is the time taken to move the image, moving an 892x750 jpeg left by 20px in setInterval I got these approx loop counts after 10 seconds:

delay=1000ms count=10
delay=100ms count=88
delay=10ms count=413
delay=1ms count=442

[d000hg]

What problems do you see? All correct but jumpy, individual images moving relative to each other during steps, etc?

[OwlHoot]

Glad I never bothered learning silverlight though!

Me too, all those poor Silverlight experts.

WTS - With all these burgeoning web technologies, it's great when one of them never takes off, as it's one less thing to worry about not having on one's CV.

I'm currently learning Dojo, in clientco's time (and with their blessing). That looks far more useful than yet another bloated Microsoft technology. Some permie hacker managed to use Dojo, Prototype, and Jquery in an elaborate and wildly over-engineered web app, and I've been tasked with enhancing it.

(Five Times, if you're reading this, it's the Release Registration Tool )

[d000hg]

WTS - With all these burgeoning web technologies, it's great when one of them never takes off, as it's one less thing to worry about not having on one's CV.

On the other hand if you learn them, it can be a great money spinner. The banking sector is big into Adobe Flex right now, paying £600+ for dev roles.

I'm currently learning Dojo, in clientco's time (and with their blessing). That looks far more useful than yet another bloated Microsoft technology.

Useful how? The whole point of SL & Flex is developing RIAs which do stuff traditionally difficult or impossible in regular HTML. The gap is closing but on the browsers people currently use, it's still there.

[NickFitz]

Oh... I figured that was too obvious to suggest to a seasoned developer. But then I come from a game-development background, different low-level domain knowledge.

I too served my time as a game developer in the Eighties/Nineties

One thing that I can't understand nowadays is all this "my new rig gets fifty million fps" stuff that people go on about. If the display is refreshing at, say, 70HZ, you'll get 70fps that actually have any effect on your sensory organs, full stop. Rather than rendering more fps, the application should be doing useful work, like "AI" and such, that's processor-intensive but can be amortised across multiple rendering cycles. If I'd ever written something that could render multiple frames that the punter would never see, I'd have soon come to the conclusion that I was doing it wrong.

Or have they ****ed up with modern games like Doom and tied their background processing to the frame refresh cycle?

[NickFitz]

That may be a factor but with larger images the main problem is the time taken to move the image, moving an 892x750 jpeg left by 20px in setInterval I got these approx loop counts after 10 seconds:

delay=1000ms count=10
delay=100ms count=88
delay=10ms count=413
delay=1ms count=442

The major part of that is going to be down to how quickly the system can redraw the changed parts of the display, which is mainly dependent on the hardware. A machine with on-motherboard graphics hardware that uses a chunk of main memory for the screen buffer (which causes processor wait states by hogging the bus) is going to do better than a machine with no graphics hardware (where the processor is spending most of its time doing redraw calculations and hogging the bus) but worse than a machine with a dedicated graphics card (where the redrawing is handed off to a separate processor and memory accesses take place on a separate bus, and the processor can get back to business almost straight away).

BTW, there's no point ever using less than 10ms for setInterval or setTimer: no browser deals with timer ticks more often than every 10ms, no matter what hardware it's running on. That's 100fps, which is more than enough to keep the human eye happy - but of course it often isn't anything like 100fps, for the reasons I outlined above. If you're running the timer for another reason, it's worth knowing that your 2.5ms updates aren't ever going to happen on schedule on any browser in the real world

[MarillionFan]

On the other hand if you learn them, it can be a great money spinner. The banking sector is big into Adobe Flex right now, paying £600+ for dev roles.

Useful how? The whole point of SL & Flex is developing RIAs which do stuff traditionally difficult or impossible in regular HTML. The gap is closing but on the browsers people currently use, it's still there.

BI 2.0 is one of the areas that Flex / Silverlight technologies are being implemented. I'm presently working with a large OEM on the concept for a number of marketing/sales tools. The technology is not agreed upon, but the outputs are. As said the first prototype for another client in Silverlight(while looking fantastic) just didn't cut the mustard in terms of performance.

[VectraMan]

The usual cause of jerky animation, though, is the assumption that an interval timer set to fire every 20ms will fire every 20ms, regular as clockwork. This isn't a valid assumption as the timer could be delayed for any number of reasons, whether it be an external process hogging CPU so the browser itself doesn't get the chance to trigger the timer event on time, to the browser itself being occupied with some long-running task like garbage collection.

Is there a good way of doing a proper "game loop" in browser based JS? All the examples I've seen use timers, and worse suggest you use lots of different timers for different animated objects, which sounds like a recipe for overhead and inconsistency.

In Windows, I've seen people use WM_TIMER messages to do animation, but the much better way is to rewrite the main application message loop to include updating the animation, but that won't work in something that's totally event driven. And presumably if you go into an endless loop in JS, the browser is going to treat that as a hang.

In Flash, being frame based, you can have an onEnterFrame event that's triggered at the frame rate of the movie, which at least means everything runs consistently even if it can sometimes get behind if the renderer can't keep up.