9 ms·
Show HN: Canvas engines performance comparison – PixiJS, Two.js, and Paper.js
- polskibus 6y agoWhat can I use if I need more performance than 2d canvas can give me? WebGL ?
- gnykka 6y agoWebGL is the fastest for now. But not all libraries and browsers support it
- huy-nguyen 6y agoWebGL 1 support in the wild is roughly 97% and WebGL 2 is 54% based on stats collected from a number of participating sites. https://webglstats.com/ https://webglstats.com/
- huy-nguyen 6y agoMakes sense because PixiJS uses WebGL2 by default, falling back to WebGL1 and then 2D canvas.
- gnykka 6y agoYes, I agree. I also found out that Two.js redraws 5k elements even a little bit faster but it takes a couple of seconds to render them for the first time.
- vardump 6y agoTwo.js was fastest on my flagship Android phone with 5k elements. PixiJS was expected to perform best? But on my flagship iOS device PixiJS got top spot, two.js close behind.
- mkalygin 6y agoInteresting. On my iOS device and on MBP PixiJS is the fastest. Any idea why PixiJS can be slower on Android devices?
- cchance 6y agoOn my laptop PixJS was easily winner when it went to 5000 at 1000 Pix and Two were equal at 144fps, but two really sucked at all levels
- codazoda 6y agoSame on my Pixel 3a when rendering 2,000. two.js is faster. At 1,000 they're neck and neck.
- butz 6y agoCould you add a switch to change renderer, where possible (e.g. on PixiJS)? I would be interesting to compare all engines on same renderer.
- gnykka 6y agoActually I made a switch at first as I started with Two.js and there are 3 types (svg, canvas and webgl). But then there was Paper.js which only had simple canvas so I removed the switch at all and used the fastest renderers for every engine (webgl or canvas).
- mellow2020 6y agohttps://jsfiddle.net/vas71r68/3/ https://jsfiddle.net/vas71r68/3/ Don't do stuff like pushing rectangles to an array to have their position wrapped, instead of simply doing it right there, unless you want to test the GC.
- ncr100 6y agoLOL this looks like 60 FPS for 5000 rectangles and _no_ canvas engine .. stock. The three of the article are 10-20 FPS. (Pixelbook c0a) Correct me if I am wrong. Nice optimization.
- deleted 6y ago[deleted]
- gnykka 6y agoMy point was more to compare libraries than to create the best canvas performance. But you are right: simple plain canvas is usually pretty fast.
- mellow2020 6y agoYeah, by default it's accelerated anyway, at least if depending on browser and hardware. So, at least for something as basic as drawing a lot of things with the same color, engines and additional code can only make it slower. Generally speaking, avoid GC, and avoid setting state that's already set... if you do these two things and use engines that do these two things, it's usually going to be more than fast enough :)
- dom96 6y agoWhat might be more interesting is drawing performance of images. And yes, a comparison with plain old canvas would be nice too.
- z3t4 6y agoIts nice if you can avoid creating new objects, but in recent optimization I've seen no difference between reusing objects vs immutable objects. Removing unnecessary code is always nice though.
- negativegate 6y agoPixiJS is the only one to reach above 100 FPS on my desktop, though that's inbetween frequent GC pauses. Two.js gets ~70 and Paper.js gets ~48. There would probably be less GC pauses if the benchmark code wasn't doing things like [...Array(this.count.value).keys()].forEach(...) instead of a for loop.
- ncr100 6y agohttps://news.ycombinator.com/item?id=23084576 https://news.ycombinator.com/item?id=23084576 see
- gnykka 6y agoGood point. Usually I like to use map or reduce for arrays but here simple for is easier.
- gnykka 6y agoI made a change to loops to use for() cycle, thanks
- bartread 6y agoI see people doing this crap all the time in the middle of tight loops that do a lot of work in C#, JS, TypeScript, and justifying it on the grounds of "productivity" and "readability". It seriously gets on my nerves. Do not do this. Functional code might look nice but often creates excess work for the GC and kills performance. We had a situation within the last week where a piece of code was blowing through 350MB of memory unnecessarily, and massively slowing down a heavy set of calculations, because of exactly this kind of issue.
- johnfn 6y ago> ustifying it on the grounds of "productivity" and "readability". It seriously gets on my nerves. Do not do this. On the contrary, please do this. "productivity" and "readability" are important aspects to consider when writing code, especially if someone else is going to be reading it. When you've identified a bottleneck, feel free to write the code in the bottleneck more performantly, if necessary. But please do not sacrifice readability across the entire codebase for a couple of hot loops.
- onion2k 6y agoI use Paper.js in my main project, and if you want to make a 2D game or something it would be a terrible choice. It isn't fast. However, it gives you a ton of extremely useful tools (like calculating intersections between arbitrary paths) with a very well thought out API. For interactive diagram generation it's great. The performance is still a solid 60fps if you limit what's getting updated to fewer than 20 or so things at a time.
- LoSboccacc 6y ago> if you want to make a 2D game all of these are quite low level engines, nothing wrong with that but there's wrapper around these, like phaser which uses pixi as backend and give quite some useful abstractions on top of the rendering.
- darkwinx 6y agoFYI, Phaser 3 doesn't use Pixi as backend.
- nogridbag 6y agoI might be the only one but for such a simple website I found the menu confusing. When changing renderers, the order appears to change every time so I forgot which one I was previously looking at. Also, the Count is always reset back to 1000 so it's annoying to compare renderers at the highest count.
- cchance 6y agoNot just you, super frustrating for such a simple thing.
- gnykka 6y agoI wasn't thinking about this as a menu, this are just links to switch between renderers. Count saving is a good point, I'll add this feature
- superqd 6y agoYou were not the only one
- dpacmittal 6y agoYou're not alone. Super annoying, especially on a phone
- xmonkee 6y agoWhy is it that if I have a video playing in another tab, the FPS goes from 60 to 10?
- nougatbyte 6y agoIts a browser feature to save performance
- tobyhinloopen 6y agoTimers and JS get throttled for inactive tabs and windows.
- hoorayimhelping 6y agorequestAnimationFrame stops its timers when tabs become inactive. To fix this, reset timer values when the browser tab receives focus. https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibi...
- opwieurposiu 6y agoFrom this I conclude I should try using Two.js for my game. I have been limited to drawing 4k neutrons for performance but Two.js might be a better solution. https://darrell-rg.github.io/RBMKrazy/ https://darrell-rg.github.io/RBMKrazy/
- yokto 6y agoPaper.js simply isn't meant to be used to draw thousands of rectangles. You should only use something GPU-based for that, like Pixi or Three. I love Paper.js because it has a TON of super useful vector features and is still is reasonably fast :D
- gnykka 6y agoI simply loved the examples on paper.js webpage and just wanted to try it
- jansan 6y agoThe boolean functionality in Paper.js is quite outstanding. I am not aware of any other Javascript library that features such a robust implementation of path unite/intersect/subtract/exclude operations.
- deleted 6y ago[deleted]
- andai 6y agoSeems performance is much better with sprites: https://pixijs.io/bunny-mark/ https://pixijs.io/bunny-mark/ I get 10,000 bunnies at 60fps but only 2,000 rectangles.
- sktrdie 6y agoI'm a total newb with GPU stuff on the web. But am curious why aren't these GPU frameworks used to render most website? Things such as facebook for instance I imagine would be a lot snappier. Am I missing something?
- Bnshsysjab 6y agoA few screws if you think websites need to be even more bloated ;)
- winrid 6y agoWell, the browser already uses the GPU to render. The difference is how you manage state. A lot of web applications do that in a slow way by storing data in the DOM for example, or do things that require the browser to re-render the whole scene. You could port FB to Canvas and it'd probably be faster until you add a ton of abstraction to give you what HTML does.
- DevKoala 6y agoBecause of browser support honestly. Outside of grid-layout, there is nothing salvageable from the CSS layout engine that cannot be done better inside a programmable view such a canvas. Give it 5 years or so for WebGL/WebGPU to standardize, and new UI libraries with a better layout engine and UI constructs far better than what can be built on top of HTML/CSS will show up. Nobody thought we would take HTML/CSS as far as we have, but it has already served its purpose. Your comment reminds me of this article back then: https://engineering.flipboard.com/2015/02/mobile-web https://engineering.flipboard.com/2015/02/mobile-web
- Freeboots 6y agoNot exactly on topic, but cycling the links is extremely annoying.
- jakecopp 6y agoHow do these compare to https://p5js.org/ https://p5js.org/ in terms of performance? I've only used p5.js.
- yokto 6y agoTo quote my dear teacher on this "Anything will be faster than p5."
- johnfn 6y agoSomething is definitely up with this benchmark - PixiJS can handle over 60k objects at once in this benchmark without even dipping below 60FPS: https://www.goodboydigital.com/pixijs/bunnymark/ https://www.goodboydigital.com/pixijs/bunnymark/ I checked the source briefly, and the problem is that the source draws every single rectangle manually every single tick. That's very inefficient. Just draw a rectangle to a Texture once, and create a bunch of sprites using that Texture. Pixi should be able to handle at least 10x the amount of rectangles if you do this.
- jansan 6y agoThat demo is insane. Din't know the browser was capable of this.
- munchbunny 6y agoIt’s WebGL underneath, which explains the ability to render really fast. You’re not drawing individual shapes so much as shoving data structures into the graphics card. (That’s not a statement on how impressive this is, just a “oh that’s how it’s done.”)
- Tade0 6y agoAll thanks to WebGL. I've been using this exact test for years now to judge a phone/tablet before buying/recommending - devices with the exact same SoC can differ wildly in performance. Nowadays any phone that can't display 20k bunnies at 20FPS likely has: 1. An underpowered GPU. 2. Badly designed cooling. 3. A screen with a too high resolution. Of course there are many more thorough and appropriate benchmarks, but this one doesn't require you to install anything and will give you an answer before you're approached by the store staff inquiring what is it that you're trying to do with the merchandise.
- kbenson 6y ago> Nowadays any phone that can't display 20k bunnies at 20FPS likely has Given my aging Samsung Galaxy S6 averages about 30FPS for 20k bunnies in Firefox mobile, your criteria might actually be too lax... Edit: And in Chrome on the same phone I'm in the mid 30's FPS for 50k bunnies.
- mattmar96 6y agohttps://matttt.github.io/sotu https://matttt.github.io/sotu Phew, glad I picked Pixi.js for this then. I’m building the next version of Scale of the Universe (For windows/mac/linux only btw)
- diath 6y ago> (For windows/mac only btw) What do you mean? It's a website.
- haack 6y agoThis is really cool. Do you selectively render depending on the zoom level? (I looked for source but could only find the minified js on your github)
- mattmar96 6y agoYeah, I have basic culling implemented. Objects that are larger than, say, 3x their normal scale are not rendered. Likewise with those 1/100th their normal scale.
- itsajoke 6y agoThe performance on my phone makes me sad. PixiJS can barely hit 30 fps and the others do worse than that. FWIW, I have a Pixel 2 phone and I'm using Firefox.
- yokto 6y agoDon't worry, the benchmark is not optimized and only testing a very specific thing, you can still do awesome complex stuff running at 60fps with any of these libraries :)
- sunpazed 6y agoMy iPhone XR has better performance than both my 15" and 13" Macbook Pro laptops. Quick, someone put a A13 Bionic in a real machine.
- AshleysBrain 6y agoShameless plug here, but I made a quick-and-dirty perf test that does something similar in our HTML5 game engine Construct 3, and it appears to run way faster even with 20000 boxes: https://www.scirra.com/labs/boxperf/index.html https://www.scirra.com/labs/boxperf/index.html This kind of test is easy work for a well-batched renderer. You can accumulate everything in to a single big typed array, copy to a single vertex buffer, and do one call to drawElements() in WebGL, and bingo, tens of thousands of sprites drawn in one go. I've got other similar performance tests that can do hundreds of thousands of sprites @ 30 FPS (on a high-end machine), which I believe are bottlenecked mainly on memory bandwidth, because I only managed to make it go faster by reducing the size of the JS objects involved. Modern JS is ultra fast - if you have the right performant coding style.
- mkalygin 6y agoFWIW the code in the post doesn't use sprites. I think it is done intentionally because not all of the engines support sprites. As someone mentioned in this thread if PixiJS would use sprites, it could be 10x faster.
- SigmundA 6y agoPaper.js looks the best on my Mac on a 4k monitor 200% scaling. The rectangles in the others look like the are upscaled from a lower resolution. Canvas vs WebGL?
- mkalygin 6y agoAFAIK Paper.js doesn't support WebGL and uses canvas. WebGL also applies anti-aliasing, which may be a reason of blurring.
- SigmundA 6y agoMy understanding is canvas also applies AA the rectangle lines still look AA just at a higher DPI. It looks to me like the rectangles done in WebGL are drawn at the scaled resolution (1920 x 1080) vs the unscaled resolution (3840 x 2160), whereas the canvas is DPI aware and drawing at the full 4k resolution. I would need to dig further but basically in WebGL the rectangles are drawn to a texture at the lower res then upscaled just like a straight image of a rectangle prerendered would be at the lower dpi. Edit: Looks like paper.js is specifically HiDpi aware and it can be turned off for better performance which would be more fair when compared to the other implementations: http://paperjs.org/tutorials/getting-started/working-with-paper-js/ http://paperjs.org/tutorials/getting-started/working-with-pa... hidpi="off": By default, Paper.js renders into a hi-res Canvas on Hi-DPI (Retina) screens to match their native resolution, and handles all the additional transformations for you transparently. If this behavior is not desired, e.g. for lower memory footprint, or higher rendering performance, you can turn it off, by setting hidpi="off" in your canvas tag. For proper validation, data-paper-hidpi="off" works just as well. Also PixiJS seems to support HiDpi if resolution is set properly: https://pixijs.download/dev/docs/PIXI.settings.html https://pixijs.download/dev/docs/PIXI.settings.html // Use the native window resolution as the default resolution // will support high-density displays when rendering PIXI.settings.RESOLUTION = window.devicePixelRatio;
- rikroots 6y agoI had to code up this test for my canvas library. Results are ... well, Scrawl-canvas isn't Pixi.js fast! But the results aren't too bad - I can live with that sort of speed. Especially as the library is entirely 2D with no WebGL magic added to the mix. https://codepen.io/kaliedarik/pen/PoPQGxz https://codepen.io/kaliedarik/pen/PoPQGxz