It reminds me of two other recent demoscene productions, also shader-based:
Waillee, in 4kB: http://www.pouet.net/prod.php?which=71873
Fermi Paradox, in 64kB: http://www.pouet.net/prod.php?which=67113
Also, elevated from RGBA should probably be mentioned since iq (https://www.shadertoy.com/user/iq) is the guy behind Shadertoy. (Also because it's pretty.) http://www.pouet.net/prod.php?which=52938
I don't know enough about this stuff to figure out if it's a false positive, but there you go.
Some background here: https://conspiracy.hu/about/antivirus/
The only solution is to report the false positive to antivirus vendors, but it takes a lot of time.
Also, seeing that some AV will alert on even the presence of an empty folder that happens to share the same name as actual malware or a completely innocuous Hello World, it's hard to recommend any. That and the detection of cracks and keygens (which goes beyond "antimalware", IMHO) further strengthens my opposition against what is essentially censorware.
- Radeon RX 580
- 1440p Resolution
- Linux 4.12 with Mesa 17.3.2
At first I thought the demo was broken entirely or was designed as some stress-test because Chrome churned between 0.6 to 0.9 fps. Never cracked 1.0 (yes, never passing one-point-zero).
Then I opened Firefox and not only ran, but never dropped below 30 fps, mostly hovered between 40 and 50.
- Radeon Vega 64
- 4k resolution
- Linux 4.15.4 and Mesa 17.3.5 (Fedora 27)
Firefox locked to 60 fps (is there a way to disable vsync?); Chrome hovering somewhere between 9 and 16 fps.
That's on Chrome. On FF with same laptop...butter-smooth 60fps with no heat.
Whatever this thing is it definitely doesn't like Chrome.
Arch has a recent thread about it: https://bbs.archlinux.org/viewtopic.php?id=234241
Amazing. Just amazing.
But be aware that it can cause some collateral damage like broken websites (if you have it and it bothers you, you can simply turn the flag off again). For example, with my Haswell Intel GPU I had never any problems, but with my Radeon it results in some strange textures on some website. FF has no problems with neither of them.
Edit: 60fps with Low Power Mode off.
http://www.pouet.net/prod.php?which=69658 / http://www.pouet.net/prod.php?which=68375
Their coder Ferris answered some questions about the implementation here:
If you stick a "vol = 0.;" before the final line of the shader (that says "return Wind(time.05) vol;") it should be silent.
I am both biased and hopeful since I am working on something very related, but my take on this is that the 3D part of the web will grow much faster than the non 3D part . This growth will mainly be driven by non gaming 3D content that do not need high quality graphics to be relevent or entertaining.
VR and AR are better understood when we realize that they are just means to the end of consuming a wider variety of 3D content in a more engaging fashion.
The percieved lack of interest about VR is absolutely not about technical limitations (such as HMD weight, resolution, controllers, wire or whatever) but it clearly is about the layman having no 3D content as relevant to his daily life as let say Facebook, YouTube, LinkedIn, Amazon etc. The first big VR company will launch a product that will be useful both in and out of VR and the web is the platform the most likely to host it.
 Most (say over 70%) of the web will stay 2D for a VERY long time though
 Most people who try VR HMDs enjoy the experience just fine (for the least). They just have no reason to try it again, and even less reason to pay money for that.
(I'm aware that at least Chrome does some syntactic checks on the shader syntax)
There can still be issues, but it isn't quite as much of a free for all as the above comment sounds.
"This issue allows attackers to capture screen shots of private or confidential information"
Todays WebGL implementations take care to wipe new memory allocations with zeros before letting the untrusted script do anything with them though.
That being said, I wish I had the patience to do something like this :)
I'm currently using my own simple test rig, but I'd like something more refined.
When studying existing shaders, it's best to focus on the well-documented shaders that are a few steps beyond your current capabilities, rather than the ones that consist of hundreds of lines of single letter variables and incomprehensible math. As far as open source repositories go, it doesn't get much better than shadertoy (in terms of pedagogy) since you can easily tweak values and comment out pieces of code right there in the browser if you're trying to figure out what a certain line of code does. The in-browser editor makes reverse-engineering very efficient and reduces friction as much as possible, which is really helpful for this kind of dense mathematical code.
Once you get used to the whole process of reverse-engineering shaders, you'll quickly come to see shadertoy as the perfect place to learn how different visual effects and graphics techniques are achieved. I don't know of anywhere else on the web (except perhaps codepen) where you can so immediately go from viewing a visual effect in a gallery to messing around with the code in nearly the exact environment that it was created in.
Edit: the best resource I've come across for learning raymarching (the 3d rendering technique used in the shader that is the subject of this submission) is this tutorial by Jamie Wong: http://jamie-wong.com/2016/07/15/ray-marching-signed-distanc...
Isn't it just rendering two triangles with a fragment (pixel) shader executing purely on the GPU. I mean, why would that be any slower in a web browser than anywhere else? (Unless the shader compiler is pretty bad?)
Are pure WebGL fragment shader demos really significantly slower in a web browser? If so, why?
Viewed through the lens of someone that lived through PCs requiring programs written in x86 assembly and be the only thing running on the bare metal to achieve anything close to 60FPS for full-screen faux-3D in 320x200 in 256 colors and well.. yes, this is absolutely incredible that a damn web browser can do this stuff in a tab - and it's entirely due to how fast processors (including GPUs) have become.
I'm aware the shader is being throw at the GPU and that's the majority of the complexity, but the GPU is part of the incredible progress consumer hardware has made.
The browser being in the loop just furthers the impressiveness; there's a bunch of other software running on the computer while this is going on in a damn tab.
So its neither a Linux nor an open source driver problem. Maybe your hardware is in fact not up to the job or you need to install some updates ;-)
Btw. I also tested chrome and as long as I run it with default settings I get around 3-5fps, but when I activate #ignore-gpu-blacklist in chrome://flags it reaches 60 fps there too.
The code copied to a pastebin: https://pastebin.com/f4uFYMzy
Recorded webm with the shadertoy-integrated record tool: https://gfycat.com/CrazyMassiveBluewhale or https://webmshare.com/vPx9d (sorry for having the tab in the background while recording :P)
But it worked fine on my Debian Stretch laptop with Intel integrated graphics. MED was pretty slow, but VERY_LOW and LOW detail levels were fine.
Here's an example: