Web GL
category: code [glöplog]
Quote:
...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.
not sure Youtube would have same popularity if it was a simple binary exe file streaming flv from servers...
Different targets, Youtube is basically compressed bits arriving at a client.
MY thoughts were more in the day: people trying to do "fancy-wow" stuff with webGL, and wondering themselves "why this fu%&$ng shit is so slooooow"
WebGL could be nice to add some 3d smell to designs, but is premature risk to use it intensively ...demos! I mean why use a such specific API wich works fast sticked to a good damn javascript+browser, instead of S.O+drivers?? performace pitfail for sure, do not get surprised later ;D
Buying more powerful hardware to move a thing, do not see the spirit...maxime when you already do _that_ on a binary client with acceptable framerate.
MY thoughts were more in the day: people trying to do "fancy-wow" stuff with webGL, and wondering themselves "why this fu%&$ng shit is so slooooow"
WebGL could be nice to add some 3d smell to designs, but is premature risk to use it intensively ...demos! I mean why use a such specific API wich works fast sticked to a good damn javascript+browser, instead of S.O+drivers?? performace pitfail for sure, do not get surprised later ;D
Buying more powerful hardware to move a thing, do not see the spirit...maxime when you already do _that_ on a binary client with acceptable framerate.
Cool story, bro.
I'm bloody wishing I'm wrong, and the cooperation between webGL + 3D rendering Contexts + Javascript canvas stuff finally works as smooth as a client binary with no additional problems, more than those inherited to OpenGL extension and version issues.
I hacked iq's shader toy code in 5 minutes
into a use case for webGL, hope you don't mind iq;
It's a very quick hack, I'll clean it up in a while.
I tested with Firefox/Minefield nightly.
http://dev.vsxu.com/webgl_usecase/
Try running fullscreen (F11).
It shows how WebGL performs in fullwindow situations and reveals vsync/tearing issues quite effectively.
The results are like this:
Fast Linux desktop box (core2quad), nvidia binary drivers: 20fps, massive tearing
Windows 7, nvidia drivers, laptop, not so fast: 5fps, with aero=no tearing because the OS doublebuffers the window, without aero: massive tearing
The reason for this ugly performance? The software compositor.
into a use case for webGL, hope you don't mind iq;
It's a very quick hack, I'll clean it up in a while.
I tested with Firefox/Minefield nightly.
http://dev.vsxu.com/webgl_usecase/
Try running fullscreen (F11).
It shows how WebGL performs in fullwindow situations and reveals vsync/tearing issues quite effectively.
The results are like this:
Fast Linux desktop box (core2quad), nvidia binary drivers: 20fps, massive tearing
Windows 7, nvidia drivers, laptop, not so fast: 5fps, with aero=no tearing because the OS doublebuffers the window, without aero: massive tearing
The reason for this ugly performance? The software compositor.
Firefox will eventually use a GL compositor. Then all will be fine.. Except it's unclear wether that will come in the same version as will make WebGL a commodity amongst firefox users.. It's a wait & see-situation I guess.
Trace: Wow, it's like a Java demo only in the browser!
x'DDD
Nice Video!!!11
What is the purpose of that two ugly rectangles surrounding the screen? The blue top with letters, and the bottom white one¿???
try this new pron
"The reason for this ugly performance? The software compositor." x'DD
Nice Video!!!11
What is the purpose of that two ugly rectangles surrounding the screen? The blue top with letters, and the bottom white one¿???
try this new pron
"The reason for this ugly performance? The software compositor." x'DD
Here's some WebGL stuff I've thrown together in the past two days:
http://low.fi/~visy/previews/webgl/
The setup should scale the rendering context to browser window size and restart the WebGL stuff accordingly.
I've lifted code from Shader Toy 2.0 (which is awesome, by the way) and some WebGL examples on the net.
http://low.fi/~visy/previews/webgl/
The setup should scale the rendering context to browser window size and restart the WebGL stuff accordingly.
I've lifted code from Shader Toy 2.0 (which is awesome, by the way) and some WebGL examples on the net.
Worked fine in Safari with latest webkit installed as well (OS X) and pretty smooth on my four years old Macbook Pro.
Chrome 9 is already running with WebGL enabled by default. But some shaders aren't working. Is there any know issue about it?
@Danguafer, I have at least post an issue on angle project concerning a simple shader like Metatunnel.
When I looked one year ago about WebGL (at the time iq released ShaderToy), implementation in browsers were using raw opengl call on windows. Since then, Chrome, and later FF4.0 moved from opengl to Angle Project, converting OpenglES2.0 calls to Direct3D9 calls under windows. Some of the shaders in ShaderToy are using int-bitwise-op extension that are not part of GLES2.0 and won't work anymore. Some of the other shaders are compiling fine (at the cost of huge HLSL compilation time) but there is no output. At least, you can compile your own Angle project dll and try to debug chrome with them (verify the generated HLSL...etc). But I haven't found a way to run Chrome in single process mode in order to debug it with PIX (FF seems to be more debug friendly but It failed to debug the WebGL layer. I suspect some mixing API hooking turbulence between D3D10 - used by FF for compositing - and D3D9 - used by angle for WebGL)...
Current WebGL state seems to be working for lots of standard opengl calls/GLSL program, but anything that is using GLSL more intensively is failing to display (though compiling is working)...
When I looked one year ago about WebGL (at the time iq released ShaderToy), implementation in browsers were using raw opengl call on windows. Since then, Chrome, and later FF4.0 moved from opengl to Angle Project, converting OpenglES2.0 calls to Direct3D9 calls under windows. Some of the shaders in ShaderToy are using int-bitwise-op extension that are not part of GLES2.0 and won't work anymore. Some of the other shaders are compiling fine (at the cost of huge HLSL compilation time) but there is no output. At least, you can compile your own Angle project dll and try to debug chrome with them (verify the generated HLSL...etc). But I haven't found a way to run Chrome in single process mode in order to debug it with PIX (FF seems to be more debug friendly but It failed to debug the WebGL layer. I suspect some mixing API hooking turbulence between D3D10 - used by FF for compositing - and D3D9 - used by angle for WebGL)...
Current WebGL state seems to be working for lots of standard opengl calls/GLSL program, but anything that is using GLSL more intensively is failing to display (though compiling is working)...
This is exactly what was happening. Thanks for the info. :)
tha @lx, very useful information!
No Comply by Firefox people
I wonder what this' good for?! ATM... nothing really.
Shader compilation time in chrome is huge on my windows machine, but on my linux setup (which is far less powerful than the windows machine) shaders compile much faster.... I blame that HLSL conversion crap. Even crashes chrome some times for larger shaders.
I have tested Firefox/Minefield 4 Nightly, Opera 11.50 labs and Chrome 10. As I noticed the best is Firefox. Chrome hangs too often. Opera also good choice. But I haven't any success in running shaders with #extension GL_EXT_gpu_shader4: enable in WebGL. Also I haven't found any program to debug GLSL shaders step by step with watch window.
@Defiance: is it still 64k ;)
