If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Moonlight Now Does GPU Acceleration

11-23-2010, 08:50 PM

Phoronix: Moonlight Now Does GPU Acceleration

In the off-hours of XDS Toulouse a few of us were wondering what David Reveman has been working on lately for Novell. David was the creator of the now-defunct XGL and has worked on Compiz, Glitz, and other Linux graphics projects, but lately his work really hasn't been publicized (nor has he been present at XDS, X@FOSDEM, etc) and even other SuSE/Novell employees have been unsure what his day-to-day activities are for Novell. It turns out at least one of his recent projects has been bringing GPU acceleration to Moonlight...

Comment

and, yeh, future of web doesn't seem bright with all those corporate vendor locking and monopolization, buying off big companies by bigger assholes. there is some rumors that MS wants to buy Adobe with their flash and graphic software. oh, how fucked will we be then.

Comment

Comment

Java applets are starting to not look so bad. Java has been able to do cross-platform hardware acceleration like this for ages. Running this kind of thing on the Java vm is a way less convoluted and more versatile way of implementing rich web applications than... lets see... using javascript to manipulate DOM elements from SVG and expecting browsers to magically hardware accelarate it, hacking some limited declarative animation system into CSS3, proprietary plugins, holy buckets what a mess, and people wonder why browsers are "slow" (except they aren't unless people try doing stupid things with them). HTML5 is all hyped up because people see a few shiny features and canvas demos and jump on the bandwagon.

This Moonlight acceleration is pretty cool I suppose at least to allow accessibility to pages which unfortunately depend upon it.

Comment

Yes, "using javascript to manipulate DOM elements from SVG and expecting browsers to magically hardware accelarate it" is easily superior to loading a foreign process that hosts a VM, especially if it's one as insecure as Java or Flash.

Hardware acceleration is pretty much a solved problem - all next-gen browsers will have it (apart from Opera whose software renderer is so fast it actually doesn't need it).

Comment

Yes, "using javascript to manipulate DOM elements from SVG and expecting browsers to magically hardware accelarate it" is easily superior to loading a foreign process that hosts a VM, especially if it's one as insecure as Java or Flash.

Javascript plus markup isn't powerful or extensible enough for general purpose development. You would never write a client application so stupidly so why a web application? I hate Java and Flash, and I wouldn't call either secure. Javascript as a language is actually not that bad. However the paradigm of general application development through manipulation of web documents is even more braindamaged. That's about the least ideal solution to the problem of high performance cross-platform networked computing I can imagine.

That's why I see HTML5's specialized features as a stopgap measure and not a long-term solution. Plugins like Silverlight are marginally better, but then there's the problem of having each user install 3000 different incompatible plugin frameworks just to browse the web. The ultimate answer would be something like a standardized sandboxed bytecode interpreter, compiler-compiler, or perhaps llvm-like infrastructure targetable by arbitrary languages and capable of executing arbitrary code in any browser on any platform with acceptable performance. Java is currently the closest thing to that.

Comment

Javascript plus markup isn't powerful or extensible enough for general purpose development. You would never write a client application so stupidly so why a web application?

You are quite mistaken. Gnome Shell and Unity3d both use Javascript on the desktop.

That's why I see HTML5's specialized features as a stopgap measure and not a long-term solution. Plugins like Silverlight are marginally better, but then there's the problem of having each user install 3000 different incompatible plugin frameworks just to browse the web. The ultimate answer would be something like a standardized sandboxed bytecode interpreter, compiler-compiler, or perhaps llvm-like infrastructure targetable by arbitrary languages and capable of executing arbitrary code in any browser on any platform with acceptable performance. Java is currently the closest thing to that.

Java applets are long dead and buried. Noone uses them anymore, and with good reason: they are slow, user-unfriendly and unsafe.

Silverlight would achieve what you propose (fast, safe and a model that is far superior to HTML+JS), but Microsoft fucked this one up from the get go. They should have standardized and open-sourced it from the beginning (with patent grant). Not that Apple and Linux zealots would have accepted that, but you never know.

NaCL from Google is promising, but it won't become viable for years.

As things stand, we'll be stuck with HTML/CSS/JS/SVG and half-assed <video> and <audio> for another decade at least. And IE6 refuses to die.