SVG heat shimmer(bl.ocks.org)
bl.ocks.org
SVG heat shimmer
http://bl.ocks.org/monfera/19845caf6aa383abddaa248a3f0d2ae0
43 comments
That 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_animati...
https://groups.google.com/a/chromium.org/forum/#!topic/blink...
https://developer.mozilla.org/en-US/docs/Web/SVG/SVG_animati...
https://groups.google.com/a/chromium.org/forum/#!topic/blink...
That'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?
This 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).
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).
Runs at about 1fps on my phone, heh.
It's about 10fps on my laptop :P
it 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
Oh 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/
It uses a noise texture to do the background warping: http://dn.ht/picklecat/clouds.jpg
It also uses this image http://dn.ht/picklecat/mesmercatdisplacement.jpg as a displacement map for http://dn.ht/picklecat/mesmercat.png to achieve the fake 3d effect on the cat.
I used them in WebGL for a couple of different effects in this demo: http://dn.ht/picklecat/
It uses a noise texture to do the background warping: http://dn.ht/picklecat/clouds.jpg
It also uses this image http://dn.ht/picklecat/mesmercatdisplacement.jpg as a displacement map for http://dn.ht/picklecat/mesmercat.png to achieve the fake 3d effect on the cat.
Wow! That's awesome! Thanks for sharing...
or webgl and better:
http://tympanus.net/Tutorials/HeatDistortionEffect/
https://github.com/lbebber/HeatDistortionEffect
http://tympanus.net/Tutorials/HeatDistortionEffect/
https://github.com/lbebber/HeatDistortionEffect
I like the accompanying "laptop fans" effect :D
On 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.
Luckily I don't buy mobile phones that don't allow me to replace the battery.
If 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.
It 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.
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.
That's Android I guess.
The alternative, iOS, can't run vim.
Mobile OSs suck.
It took me literally 10 seconds to find https://itunes.apple.com/us/app/vim/id492668168?mt=8
Heat-o-vision.
It 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.
in FF it just looks like strange codec errors :)
Yes apparently I was on 120% zoom level and therefore it worked on my machine (TM)
[deleted]
Maker 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 Meanwhile HTML transforms are GPU accelerated: http://codepen.io/monfera/full/qNVzBm/ or 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.
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 Meanwhile HTML transforms are GPU accelerated: http://codepen.io/monfera/full/qNVzBm/ or 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.
To 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.
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.
Google was first with a decent SVG and they were leapfrogged. But Chrome is the most used browser, and together with Safari, WebKit leads big time over the shrinking IE and FF portion. I and my clients can't afford to do entirely different things per browser.
My area of data visualization involves e.g. time series, where a decent zoom/pan implementation and a few years of stock or weather data means that you're juggling DOM elements in and out to keep frame rate, but adding/removing DOM elements revolver style is even more expensive, introducing janks. I also tend to work on exploratory vis where it's useful to scatter all points, tween them (not as a gratuitous effect but for object constancy, to help the user keep context) etc.
Interestingly it's also Google who wants you to get minimal with payload size. Yet it's OK for them if you roll your own speedy version of SVG by bundling a 100k of three.js or make your own text rasterizer, essentially reimplementing browser functionality.
My area of data visualization involves e.g. time series, where a decent zoom/pan implementation and a few years of stock or weather data means that you're juggling DOM elements in and out to keep frame rate, but adding/removing DOM elements revolver style is even more expensive, introducing janks. I also tend to work on exploratory vis where it's useful to scatter all points, tween them (not as a gratuitous effect but for object constancy, to help the user keep context) etc.
Interestingly it's also Google who wants you to get minimal with payload size. Yet it's OK for them if you roll your own speedy version of SVG by bundling a 100k of three.js or make your own text rasterizer, essentially reimplementing browser functionality.
Actually, Opera was pretty much the only browser with useful SVG support for a long time. All other browsers plodded along with little more than basic shapes.
I was just in the process of converting all my .png icons into SVG. Should I reconsider this? Also, how well do other solutions work with CSS?
In one of my web app projects, I went the other way. I converted SVG icons to appropriately sized PNGs. That was after I found out that SVG rendering was slow on mobile, and was the culprit of janky scrolling.
Safari / Chrome don't layerize SVG content but Firefox does so you do get hardware-composited async animations when animation the transform property of SVG content in Firefox.
I'd be surprised if any browser is drawing off-screen SVG elements but perhaps some do.
I'd be surprised if any browser is drawing off-screen SVG elements but perhaps some do.
Interestingly Firefox is often quite a bit slower than WebKit based browsers even if there's not much JavaScript behind the animations, so there may be other bottlenecks.
Even simple SVG geometries (e.g. line sections) take more time to render if there are lots of other such SVG elements off-screen in the DOM. The simplest thing for a time series would be putting in a bunch of <path> elements with long 'd' path strings (and annotations etc.) and just use CSS or SVG transform to show the currently interesting part, but even such a simple use case - ideal and compact from a graphics denotation viewpoint - bumps into performance constraints real quick if you want to pan or especially zoom at 60FPS. This stuff works great with WebGL so I'm coding up splines etc. which all exist in SVG - it's a great standard that would deserve a real fast benchmark and competition among browser makers.
Even simple SVG geometries (e.g. line sections) take more time to render if there are lots of other such SVG elements off-screen in the DOM. The simplest thing for a time series would be putting in a bunch of <path> elements with long 'd' path strings (and annotations etc.) and just use CSS or SVG transform to show the currently interesting part, but even such a simple use case - ideal and compact from a graphics denotation viewpoint - bumps into performance constraints real quick if you want to pan or especially zoom at 60FPS. This stuff works great with WebGL so I'm coding up splines etc. which all exist in SVG - it's a great standard that would deserve a real fast benchmark and competition among browser makers.
I definitely need to learn more about SVG. This is really cool.
Yes 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 (click the map or move the mouse) or Nadieh Bremer's examples eg. http://bl.ocks.org/nbremer/0e98c72b043590769facc5e829ebf43f
Also if you want to generate SVG programmatically check out http://d3js.org and https://www.dashingd3js.com/svg-paths-and-d3js
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 (click the map or move the mouse) or Nadieh Bremer's examples eg. http://bl.ocks.org/nbremer/0e98c72b043590769facc5e829ebf43f
Also if you want to generate SVG programmatically check out http://d3js.org and https://www.dashingd3js.com/svg-paths-and-d3js
What'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.
Safari 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.
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.
Though 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 :-)
A WebGL implementation of SVG would crash your browser that much faster
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.