8 ms·
SVG heat shimmer
- th0ma5 10y agoRuns at about 1fps on my phone, heh.
- tiglionabbit 10y agoIt's about 10fps on my laptop :P
- monfera 10y agoit just uses a setInterval with 100ms so your kit might be able to do more - bl.ocks can be forked with http://blockbuilder.org/search http://blockbuilder.org/search
- dhotson 10y agoOh neat, I didn't know you could do this in SVG. Very cool! Displacement maps are really useful for achieving a bunch of graphical effects like this. I used them in WebGL for a couple of different effects in this demo: http://dn.ht/picklecat/ http://dn.ht/picklecat/ It uses a noise texture to do the background warping: http://dn.ht/picklecat/clouds.jpg http://dn.ht/picklecat/clouds.jpg It also uses this image http://dn.ht/picklecat/mesmercatdisplacement.jpg http://dn.ht/picklecat/mesmercatdisplacement.jpg as a displacement map for http://dn.ht/picklecat/mesmercat.png http://dn.ht/picklecat/mesmercat.png to achieve the fake 3d effect on the cat.
- malkia 10y agoWow! That's awesome! Thanks for sharing...
- leeoniya 10y agoor webgl and better: http://tympanus.net/Tutorials/HeatDistortionEffect/ http://tympanus.net/Tutorials/HeatDistortionEffect/ https://github.com/lbebber/HeatDistortionEffect https://github.com/lbebber/HeatDistortionEffect
- themodelplumber 10y agoI like the accompanying "laptop fans" effect :D
- pjmlp 10y agoOn mobiles some WebGL demos have forced me to take out the battery, because I couldn't even kill the browser application or do the whole long button press for full restart. Luckily I don't buy mobile phones that don't allow me to replace the battery.
- stephenr 10y agoIf the hardware + OS are so deficient that your only way to stop a WebGL demo is to take out the battery, I'm not sure "lucky" is the word I'd use to describe your situation.
- swiley 10y agoThat's Android I guess. The alternative, iOS, can't run vim. Mobile OSs suck.
- stephenr 10y agoIt took me literally 10 seconds to find https://itunes.apple.com/us/app/vim/id492668168?mt=8 https://itunes.apple.com/us/app/vim/id492668168?mt=8
- pjmlp 10y agoIt was Android 4.3 on a Samsung S3. Capable of doing OpenGL ES 3.0 without sweating in native code and my usual test device for quality WebGL demos, always with the latest Chrome version.
- zamalek 10y agoHeat-o-vision.
- 10y ago
- amake 10y agoIt doesn't look right at all on Firefox: the "shimmering" bits are extremely localized (just a few pixels) whereas in Safari and Chrome they are much more spread out.
- anotheryou 10y agoin FF it just looks like strange codec errors :)
- monfera 10y agoYes apparently I was on 120% zoom level and therefore it worked on my machine (TM)
- deleted 10y ago[deleted]
- monfera 10y agoMaker here. I meant it as a way of saying good-bye to SVG as for the past years I mostly work with WebGL. A couple of other bl.ocks will be up soon. It turns out that despite its name, Scalable Vector Graphics it isn't. Sure it's scalable _spatially_ but it's not scalable _temporally_. A.k.a. slow. SVG only recently became capable of 60FPS (with only a few elements, of course). Until this year, it was capped at ~40FPS. Also, SVG was meant for graphics and the HTML DOM wasn't. Yet SVG transforms are NOT hardware accelerated, click on Paint Flashing in Chrome Dev Tools / Render: http://codepen.io/monfera/pen/JKOqyY http://codepen.io/monfera/pen/JKOqyY Meanwhile HTML transforms are GPU accelerated: http://codepen.io/monfera/full/qNVzBm/ http://codepen.io/monfera/full/qNVzBm/ or http://codepen.io/monfera/full/BzmERz/ http://codepen.io/monfera/full/BzmERz/ (no green rectangles flashing) There's also a big overhead of just having a lot of SVG elements even if they're presently off-screen (in which case WebGL wouldn't draw it or even if you call gl.drawArrays on them it doesn't hit the shaders). Having done WebGL I feel that a transpiler from SVG filters to WebGL I could hack together would be an order of magnitude (usually I get an order or two magnitude speedup when moving a plot to WebGL). Someone at a major browser vendor confirmed there hasn't been significant work on SVG for many years. SMIL is now out. The hardware accelerated HTML DOM, Canvas and WebGL are eating SVG's lunch. I suspect it's one of the reasons the new D3 4.0 adds more separation of concern between logic and rendering, and there's a wealth of Canvas based examples from Mike Bostock and others. To paraphrase Greenspun's tenth rule: Any sufficiently complicated Canvas/WebGL 2D data visualization contains an ad hoc, informally-specified, bug-ridden, but FAST implementation of half of SVG. And it's sent down the network each time, including mountains of font rasterization.
- ygra 10y agoTo what extent SVG is hardware-accelerated entirely depends on the browser. Chrome was quite late to the party of making drawing fast and it often shows (it redeems itself with a fast JavaScript implementation in complex applications that have a lot of rendering and computation). But the raw drawing (of SVG, not canvas) has been a lot faster in IE for quite a while. I'm working on a graph drawing library at work and for our web product we rely on SVG. In my experience the performance is good enough for our purpose at least (graphs are a thing that becomes more or less unreadable as the number of entities go up, so useful graphs tend to only have a few hundred nodes/edges on the screen at most; and that's still effortlessly possible with 60 fps interaction). Where it gets annoying is that especially Google clearly doesn't really care for SVG. It's not used (much; or only with static images) in the top 500 sites or whatever they look at for optimising their browser, so they frequently break things with rendering that come to bite our customers.
- rado 10y ago200% CPU Safari, 80% Chrome.
- tempodox 10y agoI definitely need to learn more about SVG. This is really cool.
- monfera 10y agoYes SVG is very powerful denotation. FWIW I prefer my other current example (I'll wrap up a third one soon), procedural map generation and reflection bump map with SVG http://bl.ocks.org/monfera/21be9bb116a8e5b2423b706155fdb718 http://bl.ocks.org/monfera/21be9bb116a8e5b2423b706155fdb718 (click the map or move the mouse) or Nadieh Bremer's examples eg. http://bl.ocks.org/nbremer/0e98c72b043590769facc5e829ebf43f http://bl.ocks.org/nbremer/0e98c72b043590769facc5e829ebf43f Also if you want to generate SVG programmatically check out http://d3js.org http://d3js.org and https://www.dashingd3js.com/svg-paths-and-d3js https://www.dashingd3js.com/svg-paths-and-d3js
- tptacek 10y agoWhat's the difference in how Safari handles this? I use Chrome, and it looks OK. But just loading the page on Safari slows everything else on my machine down.
- monfera 10y agoThough both are on WebKit, they use different renderers. Generally Chrome is better than Safari except on iOS where Apple forces other browser makers to use the Safari engine, I guess it's one way of keeping tabs on mobile browser speed competition :-)
- pcwalton 10y agoSafari uses Quartz/Core Graphics for the painting, via OpenGL if applicable. Chrome uses Skia/Ganesh, sometimes via OpenGL--Chrome is more conservative about when it enables the OpenGL-based painting than Safari is, I believe. If everything else on your machine is slowing down, then chances are good that Safari is hitting some bad case in the way it uses your GPU. CG::OGL may not be optimized well for this use case. (In general retrofitting CPU-based 2D graphics APIs to run on GPUs, as both Chrome and Safari attempt to do, is difficult.) Or the layerization heuristics may be going awry in Safari--unlike Chrome, which does things manually, Safari has a completely different implementation of layers that exports the layer structure of the page to the OS window server.
- PaulHoule 10y agoA WebGL implementation of SVG would crash your browser that much faster
- kazinator 10y agoThis looks like drops hitting glass (but then disappearing, as if they vaporized). Or perhaps "heat shimmer" of another type, if we can call it that: what you might see in your field of vision if you've been running a long distance along that road, without drinking water. Heat shimmer has to be sort of stringy due to the currents of different air densities that move as aggregates. It's mostly vertical as the plumes of hot air rise from the ground, so most of the distortion is horizontal displacement (side-to-side jitter).
- j4_james 10y agoI was curious if this could be achieved without the need for JavaScript, and I see there is an SVG animate element that looks like it ought to do the trick. In theory you should be able to get the turbulence seed to cycle from 0 to 500 by adding an animate child on the feTurbulence element like this: <feTurbulence id="turb" baseFrequency="0.2" type="turbulence"> <animate attributeType="XML" attributeName="seed" from="0" to="500" dur="50s" repeatCount="indefinite"/> </feTurbulence> It's not quite the same as the JavaScript implementation, which makes the seed random, but I wouldn't have thought that was necessary in this scenario. Anyway, while it seems to work OK for me in Firefox, it doesn't look quite right in Chrome, and it fails completely in IE and Edge. Not sure if I'm doing it wrong, or SVG animation is just not well supported yet, but this would be my preferred solution if it could be made to work reliably.
- Arnavion 10y agoThat is SMIL, and is on the way out. IE never implemented it, and Chrome wants to remove it (but hasn't yet). CSS animations are the replacement. https://developer.mozilla.org/en-US/docs/Web/SVG/SVG_animation_with_SMIL https://developer.mozilla.org/en-US/docs/Web/SVG/SVG_animati... https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/5o0yiO440LM%5B1-25%5D https://groups.google.com/a/chromium.org/forum/#!topic/blink...
- j4_james 10y agoThat's disappointing, because CSS wouldn't be a viable replacement in this case - it can't animate XML attributes like seed. Or is that something they plan to support one day?
- Arnavion 10y agohttps://dev.w3.org/SVG/proposals/css-animation/animation-proposal.html#def_attributes https://dev.w3.org/SVG/proposals/css-animation/animation-pro...