Web GL
category: code [glöplog]
We want gnu-rocket in the web. Would be nice if it was easy to integrate as the C++ version, so I can plug it to ShaderToy for example and track the parameters of the shaders...
Oh, a parenthesis in the discussion here:
(
I'm with Skrebbel, demos in the web will be super convenient. Random reasons.
- easier to consume (let's be honest, we often watch youtube/capedtv videos of demos just because it's "one click" versus "click, download, unzip, run, setup the anoying config dialog", not because our gfx card can't run the demo)
- easier to "sell": we will finally be able to speak to other digital "art" communities in their own language (processing, java, flash guys) and get out of the little dark hole we are living in. Many sceners might not want to take this step, but others will.
)
Oh, a parenthesis in the discussion here:
(
I'm with Skrebbel, demos in the web will be super convenient. Random reasons.
- easier to consume (let's be honest, we often watch youtube/capedtv videos of demos just because it's "one click" versus "click, download, unzip, run, setup the anoying config dialog", not because our gfx card can't run the demo)
- easier to "sell": we will finally be able to speak to other digital "art" communities in their own language (processing, java, flash guys) and get out of the little dark hole we are living in. Many sceners might not want to take this step, but others will.
)
furthermore you'll be able to run demos in realtime on whatever device you want. for example, nokia recently demostrated webgl running on their n900 handset.
Quote:
furthermore you'll be able to run demos in realtime on whatever device you want
People with Intel integrated GPUs beg to differ. Hell, the x600 graphics adapter in my workstation royally nosedived on Shader Toy and failed to run any other Web GL demo -including the hey-dumbass-here's-a-cube ones.
It runs pretty well on iPhone 3GS, apparently. I'm not exactly brimming over with incentive to jailbreak mine though.
whatever device you want, hardware/driver/browser permitting then!
@iq and Skrebbel, indeed, this is a fantastic opportunity to spread demo's art. It's going to be even portable on small devices, and that's really cool.
Anyway, on my side, I still do care about lightweight intro, even if it's on the web... so I'll check a bit more about audio... I did already some easy dynamic audio rendering with silverlight 3 (here) and it's quite promising! Need to check know how well to integrate it with WebGL...
Anyway, on my side, I still do care about lightweight intro, even if it's on the web... so I'll check a bit more about audio... I did already some easy dynamic audio rendering with silverlight 3 (here) and it's quite promising! Need to check know how well to integrate it with WebGL...
i have a Intel GMA 4500 MHD card (low end and non 3d) on my 13" laptop and despite what I expected almost all presets in Shader Toys run smoothly (20-25fps).
Quote:
I'm not exactly brimming over with incentive to jailbreak mine though.
um yes, way to go on about a browser thing, me! kindly attribute this to sleep deprivation and medication :(
Quote:
i have a Intel GMA 4500 MHD card (low end and non 3d) on my 13" laptop and despite what I expected almost all presets in Shader Toys run smoothly (20-25fps).
The 4500MHD is actually quite decent (compared to 950 gma and such), has GL 2.1 support and so on.
Playing a bit with WebGL, seems one thing that might be a bit annoying is not being able to play in fullscreen with a different screen resolution. You are stick to the resolution of your desktop (which are quite high actually compare to the resolution we use in intros), forcing the WebGL canvas to be displayed on a smaller area inside the browser in order to keep an acceptable fps. From a visual experience point of view, this is going to limit the "wow" factor.
@lx, fbo?
@petemobil, i forgot that, that could be an idea, render to a smaller buffer and just stretch the buffer for the display, yep! ;)
btw kusma, i wasn't actually kidding - as iq correctly mentioned, doing http requests from javascript is very simple. keeping any other connection (i.e. some tcp socket) open for bidirectional communication is not possible, however.
so we'd need to change the protocol, so that the editor is the server and the demo is the client (already the case), but also that all commands sent from the server to the client are sent as a response to a client request, as in http the server can't just decide to send a request to a client at any random moment. this should be easily possible, though, as you want to do update() at the beginning of each frame anyway. the response could be "thanks for the update! oh and by the way please pause the demo and skip it to position x".
but this is getting very off topic, really :-)
more back on topic: after a short 10 minute investigation, it seems that firefox uses liboggplay for the audio and video tags (not entiirely sure, but the source includes liboggplay and that precisely matches the supported formats for the audio and video tags). i haven't checked, but given that liboggplay is free, cross platform, and very easily integrated it could very well be that the other OS browsers use it too.
in that case, *if* the bad resolution comes straight from liboggplay, we could just fix it there (or nag others to do so) and have an improvement in all three browsers.
so we'd need to change the protocol, so that the editor is the server and the demo is the client (already the case), but also that all commands sent from the server to the client are sent as a response to a client request, as in http the server can't just decide to send a request to a client at any random moment. this should be easily possible, though, as you want to do update() at the beginning of each frame anyway. the response could be "thanks for the update! oh and by the way please pause the demo and skip it to position x".
but this is getting very off topic, really :-)
more back on topic: after a short 10 minute investigation, it seems that firefox uses liboggplay for the audio and video tags (not entiirely sure, but the source includes liboggplay and that precisely matches the supported formats for the audio and video tags). i haven't checked, but given that liboggplay is free, cross platform, and very easily integrated it could very well be that the other OS browsers use it too.
in that case, *if* the bad resolution comes straight from liboggplay, we could just fix it there (or nag others to do so) and have an improvement in all three browsers.
About the granularity of the Date object in JavaScript, bare in mind that JS engines are usually only allowed to run every ~15ms because of stupid implementations ( without pause-resume ) that can make the browser UI non-responsive in case of a heavy script.
Quote:
: \ yeah, I'm not sure I'm happy to see a HW divide on the web. I know it's inevitable with HW acceleration stuffs but it's a tad worrying to see a web standards be completely inaccessible to a whole range of devices. ... :p maybe I'm just pissed at my Intel GMA that can't do PS 3 and make WebGL browsers crash or choke badly on all the WebGL examples I tried.furthermore you'll be able to run demos in realtime on whatever device you want
Quote:People with Intel integrated GPUs beg to differ
skrebbel: perhaps the easiest thing would be to make an "http-proxy" that buffers up updates from the editor?
skrebbel: you can delay the answer of ajax requests till something new happened on the server.
after getting an answer, the client again sends an request to the server.
there is some funky buzzword for it, but i forgot it.
facebook does it that way, you can see the delayed response in firebug.
happy xmas!
after getting an answer, the client again sends an request to the server.
there is some funky buzzword for it, but i forgot it.
facebook does it that way, you can see the delayed response in firebug.
happy xmas!
pandrr, ahyes good point. i'm so used to http on php+apache being difficult to stall that i forgot that this is of course peanuts on a homecooked http server. simplethen!
pandrr, skrebbel: the buzz word is Comet.
the web two point OH! crowd never fails to amaze with horrible buzz words.
skrebbel, it just means you're not (or close enough) a teenage programmer anymore :) (as in > 19 years of programming ;)
Them teenage programmers and their fads
Them teenage programmers and their fads
\o/ happy coding!
WEB2.0 XML MEGADEMO
Quote:
maybe I'm just pissed at my Intel GMA that can't do PS 3 and make WebGL browsers crash or choke badly on all the WebGL examples I tried
It's even more depressing when you realize that a N900 or an iPhone is better at WebGL than your GMA-equipped computer.
they should fix that up a bit
its not like the powervr in the iphone is a beast
then again the framebuffer is tiny
its not like the powervr in the iphone is a beast
then again the framebuffer is tiny
I do not see anything else but bad points:
.Sluggish fps
.Fullscreen issues
.Spending money in a new NxGPU (not bad idea if you owe some nvidia,ati,intel stock-stuff on Nasdq)
.and being more realistic, all sort of typical browser incompatibilities==additional work. So not so far from porting classic client's from one platform to another.
Notable advantages? Yes.
.Connectivity, online content.
...er...C'mon, any kid could write a simple binary with a "http-tcp" light protocol to recieve-send data from a client allover the Inet.
.Sluggish fps
.Fullscreen issues
.Spending money in a new NxGPU (not bad idea if you owe some nvidia,ati,intel stock-stuff on Nasdq)
.and being more realistic, all sort of typical browser incompatibilities==additional work. So not so far from porting classic client's from one platform to another.
Notable advantages? Yes.
.Connectivity, online content.
...er...C'mon, any kid could write a simple binary with a "http-tcp" light protocol to recieve-send data from a client allover the Inet.
