Reply to: Silverlight

[d000hg]

What are you trying to say? VB is still used in loads of legacy projects, if VB.net hadn't replaced it I bet VB6 would be used a lot more even now... VB6 is over a decade old, but SL is still in active development.

[AtW]

Certainly no concern it's suddenly going to disappear

They did it to VB and that had much stronger developer support...

[d000hg]

They never said it was being dropped, or mothballed. Only that their main focus for PCs was on HTML5. Certainly no concern it's suddenly going to disappear, and SL4 looks pretty full-featured already.

[original PM]

the more alert of you may have noticed a thread in general about me finally getting a system in place - guess what it was developed in Silverlight - so this thread sent shivers down my spine!

However we have approached MS directly about this and apparently during the PDC10 one of MS's lead developers put his foot in it and has been trying to take it out ever since.

So it would seem the rumours about the demise of Silverlight are somewhat premature......

only time will tell I suppose.

[NickFitz]

PS Don't recall any obvious instal/download but actually Streetview seems to be using ActiveXObjects.

StreetView uses Flash, which is implemented as an ActiveX control on Windows (and as a demonic swarm of soul-sucking hags on other platforms).

[NickFitz]

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.

Well, the main application message loop is just a thing that relinquishes control whilst it waits for events to arrive - otherwise, the first app you ran would consume 100% CPU busy-waiting. On a multi-tasking OS, all applications are event-driven, even if the event is the implicit one of being given a timeslice that allows an endless loop to have another go at running to infinity.

For JS, you don't need to think about the main application message loop: that's already in existence in the host context, outside the scope of your code (e.g. in the browser process or, for something like node.js, in a server process) and all you deal with is the messages that are dispatched to your code, which in the case of the browser consist of user interaction events (e.g. the user has moved the mouse over something), network interaction events (e.g. an image has loaded, or an XMLHttpRequest has undergone a state transition), and timer events (interval timer X invokes its callback). These events are all provided by the external context (note that setInterval and setTimer are both methods of the window object, not functions native to the language), which is why JS can easily be deployed in other contexts such as servers (where the events are things like "a remote host connected" or "a disk-based file has been opened and can now be read"). Either way, callbacks are king: whilst the script is being parsed it can do stuff if the context provides for it (e.g. document.write() in browsers, and the creation of variables having global scope) but after that, everything happens as callbacks from the context's event loop.

Personally, I prefer a setup that makes it clear that your code is running as and when things happen that it needs to deal with. (Any attempt to create an endless loop in JS in a browser will result in the browser stepping in and prompting the user that a script is running for too long; otherwise, Denial of Browser attacks would be all over the web.)

JS in the browser doesn't have the concept of frame refreshes, because stuff like that is abstracted away into the browser's rendering engine, which will take care of all the aspects of rendering like double-buffering and clipping content to containing views.

Incidentally, one of the reasons that Flash can be "The best way to tell if your laptop's fan still works" is that ActionScript is constructed on the same principles, but many Flash devs can't seem to get their heads around the idea of creating applications that consist entirely of callbacks; instead, they create busy-waiting loops which consume loads of CPU. The fact that Flash allows this is one of its greatest failings. It should just kill stuff that busy-waits beyond a certain time; then the errant devs would have to learn to do it properly, or be out of a job. But it doesn't, so they aren't, so Flash is a scourge. I've found great inner peace since I blocked it

[xoggoth]

What problems do you see? All correct but jumpy

That's about it. A small but noticeable jerkiness. Might be satisfactory if I (and users) hadn't seen Google Street View.

BTW, there's no point ever using less than 10ms for setInterval

Wasn't really trying to apart from above test. I don't need a fast scroll, just hasta be some way to get it a bit smoother apart from using much smaller images, not really much good for my application. 300x300 works great. There's plenty of smooth scroll "kits" (not found one that actually works yet) but from examples they all seem to use images of that size so suspect they don't have any brilliant wrinkles anyway.

PS Don't recall any obvious instal/download but actually Streetview seems to be using ActiveXObjects.

[d000hg]

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?

The FPS thing is kind of an e-penis thing, and also a way to compare system performance. There's debate at what point FPS increase gets meaningless and in fact it's a pretty complex issue, but basically there's not much difference rendering faster than the refresh rate (some small benefits potentially).

And no, logic is normally separate from FPS although I don't think it's commonly multi-threaded even these days since it's hard to decouple. Game AI might run at 10Hz, physics at 100Hz, etc.

[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.

[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.

[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

[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?

[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.

[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]

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