pouët.net

I use shadertoy and glslheroku a lot (huge thanks to authors).

Both are pretty good and advanced tools, but I have trouble browsing the effects in shadertoy :

It seems the preview are rendered realtime in low res (instead of being just a jpg/png thumbnail). For some shaders (simple ones) it works for some others it just hangs up and then webgl dies (at least with Chrome).

After one shader has failed, all thumbnails (even the ones already rendered) becomes black. So as soon as there is one pretty big shader in the list the whole page wont display at all.

I do not have a powerful card (GTX 560) maybe with a powerful GPU (eg : GTX 980) it wont happen.

What about rendering these effects as thumbnails ? (yes it would increase website bandwith and would need some storage) but it would be a great improvement.

Did somebody have similar issues or solutions ?

Shadertoy displays a static frame for thumbnails if the mouse is not hovering over them, so I imagine it would be simple to render that frame to an image and use that. The shader can be compiled and run on-demand with the first mouseover event.

That's just a suggestion. =)

I think this is the biggest problem with shadertoy and partially renders the site unusable for those exact reasons. An option to at least be able to choose to use static thumbnails should be essential. "Big" shaders aren't even the whole issue, because there are a ton of seemingly random compilation errors ith webgl even with smaller shaders.

Counter arguments for static images:

For static images there needs to be a server code which will load user written shaders. This can be a huge problem. If not handled well, instead of your browser crashing, the whole website can crash. Video card drivers are not the safest things out there. Not to mention that many hosting solutions probably don't have GPUs that can run shaders.

The way it is right now is the way how it's supposed to work. Shadertoy.com is a lightweight shader code hosting service. It is the browser's job to run the code and its the browser's job to not to crash when it load poorly written user code.

Imagine if your browser would randomly crash because of a bug in javascript. It would render javascript almost useless and all our websites would be non-interactive forms like 10 years ago with the few exceptions like shadertoy pushing the envelope.

I expect WebGL support to evolve. Everything is moving to the web because of the security and ease of access it offers. 3D graphics technology shouldn't be left behind.

And just to be clear, I have the same issues. Firefox seems to handle it better but the support in firefox is crippled elsewhere. I use both firefox and chrome to get the best out of Shadertoy.

This is indeed pretty annoying. Maybe the author could pick a frame that would be rendered in the browser and then uploaded to the server?

That might open up an opportunity for abuse, by uploading custom images.

On the opposite end, maybe if a separate context is created for each shader on the page then the browser should only 'fail' locally for each thumbnail instead of nullifying the whole page. I don't know if this can be possible in WebGL.

Or just let the user's browser create a thumbnail when they save the shader.

This is actually the case. The browser process does not crash, but all JS code after the error wont be executed, usually making the whole page unusable (many websites need javascript to work properly). To have JS work again you have to refresh the page or go somewhere else.

So to me it is very similar to behavior of webgl with non working shaders. Maybe there is one difference : you need to click on the restart button (shown on top of the page) to make it work again.

About issue for server making shader screenshot : how does it work in glslheroku ? (which actually make screenshots)

poor mans solution: dont clutter the mainpage with multiple shaders :p

I tried it on Nvidia Shield tablet (Chrome), checked the 20 first pages of "newest" and all thumbnails loads fine.

Tried it on my PC now (Chrome / GTX 970), and got shader error on page 8. Weird.

Tigrou: In glslsandbox is the client that generates the screenshot and sends it to the server as a png.

https://github.com/mrdoob/glsl-sandbox/blob/master/server/assets/js/helpers.js#L89-L106

Agree this is thé number one problem with the whole site as a content viewer.
I would suggest uploading thé image when user saves shader. User could hack and upload anything maybe, son what? User can already code a 3d cock or harcode a bitmap in source no?

Not sure why this is posted on pouet instead of sending feedback direct to iq/beautypi.



The browser doesn't crash though, it gets an error either through bad shader code or in most cases because the compile time is too long, then it just turns off webgl for that page and keeps running just fine. So I think the browser handles it ok. You can adjust the time limit in chrome that it will wait before it thinks it is not getting a response from the shader compiler which helps if you are using shadertoy or similar webgl website. That will stop the big shaders which timeout from causing a problem. Not sure if you can do the same in firefox, I personally never looked into it that much.

Problem most of the time is the front page on shadertoy shows the most popular or something shaders which are usually big raymarching routines with lots of loop iterations and loops inside loops with variable exit conditions which are always slow to compile.

I think it would be perfectly fine to use the same screenshot system that glslsandbox uses. While it is kinda nice to have the mouseover animations, I think the drawback of having it take minutes to load the page and often timeout the compiler is not worth it.

My workflow:

load - crash webgl - login - browse to shader - reload webgl

Have the software implementations of opengl kept up with the improvements around shaders? It'd be mindbendingly slow compared to hardware, but you're only after one tiny frame.

Software seems to run most shaders fine but as you say it is very slow. Problem using the software compiler instead of using the video card driver compile it takes a very long time, those big raymarch shaders with many loop iterations can take minutes to compile.

Not sure what it is like on other operating systems but the whole ANGLE converting from GLSL to HLSL on windows so it can run on the directx api just seems like a crazy way of doing things to me.

I just tried on MacOSX + ATI (less powerful than my GTX 560) :
Shadertoy works like a charm. The possibility of mouse over on thumbnail + preview is awesome. While on PC + Nvidia, loading the page just "hangs up"

These crashing previews are really annoying.
I think Gargaj's idea is on the right track. When a user is working on a shader, nothing prevents us from generating a film strip JPEG showing 8-16 frames of the shader in action, for replay via simple CSS background image ( like on YouTube when you hover the time track ). If storage is an issue, the JPEG film strip previews can be uploaded to IMGUR instead.

If the page totally hangs then it is using the browser compiler ANGLE. The browser won't respond while it's trying to compile, if you let it go for long enough eventually it will compile and respond again but it literally takes several minutes on the complex shaders. The entire front page of shadertoy can take anywhere from 10-30 minutes to compile on angle sometimes. Its completely ridiculous.

There is an option in chrome and firefox where you select "native" webGL or something like that which turns off angle. Then it compiles using the video card driver instead, this is much faster usually only a couple of seconds. But then if it takes more than a couple of seconds or any error happens then the browser just switches off webgl. You can reactivate webGL and refresh the page or go to another page but I know with chrome after a few times of it switching off webGL it drops back to total software rendering and you need to go in to the chrome flags and turn hardware support back on.

In firefox browser on windows go to about:config and search for webgl then set webgl.disable-angle to false, it will compile the shaders much faster.

For chrome you used to have to add the commandline flag –use-gl=desktop when you launched it but I am not sure how it is on the more recent versions of chrome.

Go to https://www.browserleaks.com/webgl to check that angle is disabled.

Afaik there´s an Option in Shadertoy called: Use previews (avoid compilation times):

If you just want to browse the latest shaders, shadertoy is a total pain in the ass. It just takes too much time to compile all the shaders and crashes pretty often.
glslheroku did it properly (yes you can exploit it... but at least it works).

I not a fan of this WebGL stuff at all, IMHO it's broken, especially with additional intermediate cross-compilers. Compilation times for large shaders are bad enough without that additional layer.

It's pretty easy to DOS the overview page of shadertoy:
Just create a shader with a massive compile time (if you know how compilers work, this one is easy) and a massive rendering time (you figured that one out already, right?) - bonus points for TDR timeout.

Additionally, limiting your complete prototyping to a single shader might be fun for a while, BUT you can do WAY more using the complete GPU pipeline. Prototyping shaders outside the browser might save you some time - oh and you have real GLSL/HLSL and stuff!

I was reporting this as well quite long ago and yeah probably there are a lot of potential for exploits and some boring work to be done, so i thought about it again and if Iq/Pol are reading this just consider not having any preview please =) i mean it - i'm totally fine with only having titles in the browse page, if that can happen NOW and can take less of your time.
also,
can't see anything like that. such option/'no preview' option should be a switch somewhere near the Shadertoy logo imo, having in mind how big this issue is.

ton, log on to your profile... There´s the option.
Would be cool if this would also work for non-registered users ;)