If you add a `uniform vec3 mousePrevFrame` that tracks the previous mouse position, you can get smoother drawing in main() by replacing your distance function in the line `float dist = distance(mouse.xy, gl_FragCoord.xy)` with a custom
This unfourtunatly is why GPU-enabled JavaScript on the web won't take off.
It works on iPhone and Windows desktop but does not work on iPad Pro 11, not on Galaxy S10, not on some Linux desktops. So, it is inconsistent even within the same iOS ecosystem.
Some might say the OP misconfigured or I need to go about:config, but these kinds of thing should be trivial for developers/users.
Even Flash used to work out of the box across platforms. Why things going backwards?
First of all, just extrapolating from someone's side/hobby/demo project to all WebGL pages is naive. The effort put into a demo is orders of magnitude less than a real site.
Second, "GPU-enabled JavaScript" has already taken off. Ever used Google Maps or Google Earth - both use WebGL heavily? Or maybe you read the NYTimes who occasionally produce pages with a heavy WebGL focus[1].
I mean, these kinds of things should work without highly paid devs like googlers. I have seen a lot of WebGL projects on HN and they always have had issues on some recent devices.
The biggest problem with the WebGL compatibility issue is that it is unpredictable. We don't know which devices work until we open the page. Maybe I am expecting too much, but this degree of inconsistency shouldn't happen to hobby projects neither.
I think most of this is just WebGL 1 (AKA OpenGL ES 2) versus WebGL 2 (AKA OpenGL ES 3).
If you restrict yourself to the basic parts of WebGL 1 your app will work almost everywhere, as compatibility is excellent on all recent phones and OSes.
There’s a lot of nice stuff in WebGL 2 (eg float textures, vertex textures) but as soon as you try to use it you either sacrifice compatibility on a bunch of devices, or you have to check for various extensions to try to figure out what’s going to work, and try to fall back gracefully if possible.
I've never had problems with three.js, which is what most people use for WebGL-powered content.
Are you claiming that there's less effort in coding up a native graphics program that works across all platforms?
Certainly native has the edge on performance (WebGPU will shorten the gap a bit), but on ease of multi-device compatability? I could be convinced, but it seems hard to believe. The whole idea of the browser (these days) is to make cross-platform stuff easier to develop.
1. Flash is not a standard. Flash is developed by a single company. There could not be any compatibility issues because of that. Web is moving to that direction with Chromium engine being used everywhere, but it's not there yet.
2. Flash is relatively high-level API when it comes to graphics. Shaders are low level and while they should work everywhere, I guess, one could still run into compatibility issues between different video adapters.
That said, cross platform compatibility is always going to be hard. I'm still amazed that Adobe let that platform die. It has taken so long and so much effort to recover equivalent functionality, and in some cases we are still lagging what Flash could do.
There might be something wrong with your phone, my S10 with Chrome is working well.
Edit: Actually, I remembered now there are two versions of the S10, the Snapdragon and the Exynos variants. I have the Snapdragon one, might be a difference.
I'm not sure if desktop graphics are any better. It's a reason why a lot of people choose consoles, no chance of incompatibility. But even then you have ports and games that are poorly made!
Javascript APIs used to have that same problem where you didn't know in which browser it'd work until you actually tried it and it did take off quite spectacularly. Just give it some years for platforms like Apple to catch up, but there needs to be pressure with people complaining that "it doesn't work on iPad Pro 11".
Amazing! Something I have learned from similar experiments in the past - instead of drawing a circle each frame, try drawing a (rounded) line between the current frame's cursor location and the previous frame's cursor location. Cursor movement looks much smoother that way.
It's well done, though anyone who regularly browses Shadertoy or similar websites has probably been desensitized to old-school (yes, old school!) liquid demos compared to what the cool kids do these days... but well done nonetheless!
But I'm always a little disappointed to find most them render as "Shader Error" for me. That's still better than all the WebGL demos that show a blank screen and don't seem to know they have failed!
Looks neat. Doesn't seem to work with my Razer Blade Stealth touchscreen though (touching to move mouse doesn't work like normal, touchpad has to be what moves it). Would be super cool with multitouch support.
I also get a flickery mess, on Linux + Firefox 81 with Haswell Intel Graphics. I suspect that there is some sort of uninitialised buffer/variable somewhere, and different drivers handle it differently.
It has a bit of delay. And that's why I prefer native vs web applications when performance and end user experience is paramount. This effect is implemented in ZBrush for decades now, on lesser hardware with no delay between mouse movements. Currently web applications just reinvent the wheel from old desktop ones.
The delay (or more accurately smoothing) of the mouse position is a hack to make the mouse trail look more like a streak rather than repetitive little blobs. I call it a hack because the proper solution would be to have a line-shaped source that extends between the last and current mouse positions. Native might allow you to marginally pump up the FPS, but that wouldn't save you from the little blobs.
(edit: just to be clear, I'm not the author but this issue is common enough)
I think the experience might benefit from showing the mouse pointer, or some other cursor that actually tracks your mouse and shows the blobs current "target". You will undoubtably lose something in the process, but I think it would be worth the tradeoff.
Right now, it feels difficult to control. I can never quite get the blob to do what I want, which is crucial for an interactive experience.
response for @pierrec / @scandinavian / @t0astbread:
If you move the mouse slowly there is little to no delay between the movement and the "bubbles". Moving faster and faster and the "bubbles" are falling behind more and more. This effect is even more evident when moving at the same speed in straight lines vs moving in circular motion. Which tells me there is a performance drop.
This does not happen at all in ZBrush. Do try it, it has this effect implemented for decades. I remember playing with it in 2003 on a P3 350 MHz / Win 2k as OS. There was absolutely no "loss" of mouse movements nor "bubbles" skipped as it is the case here.
I don't think we'll ever have native performance on the web as long as things like spectre are still present on earth. This would be a good opportunity to kick JavaScript, but I both expect and hope that we will move on from it eventually.
It's shocking how bad the code sharing is across iOS derivatives.
For example, the Notes app on MacOS and iPadOS will sort checklists so that completed items are moved to the bottom, but iOS will not. How the hell did they manage not to share that bit of code?
This is a very nice effect. WebGL shaders allow some really cool tricks with 2d images, and the JavaScript required is not too onerous even if you don’t use a library to help.
I used WebGL to crossfade between photographs in different (slightly cheesy) ways.
Take an old iPad and put it in a frame? Might be able to do it for $150 or less. This runs fine on my old iPad Air 2, possibly it works on even older devices?
Might be GPU blacklisting. I've encountered it with Chrome on older Samsung hardware. Try force enabling hardware acceleration in chrome://flags or about:config?
For me, it's solidly H. R. Giger - something about the juxtaposition of large smoothly shaded areas and messes of intricate detail, plus the moody monochromatism, and the fact that it has come straight from hell.
Its a ball you move with your mouse that creates some sort of liquid metal ripple effect where the ball went and ends up looking like: https://i.imgur.com/DaM4a9I.png
uniform vec3 mouse; uniform vec2 resolution; uniform sampler2D texture;
vec3 computeNormal( vec4 n ) {
}void main() {