What I am struggling with, is the use case of a library like this.
Is this oriented towards gaming or substitude something like d3.js or is it has a simplier api, for the developer than other libraries. Or is it a library to showcase the cool stuff that can be done with new technologies.
I think the main difference and the selling point is that it is "renderer agnostic" but I don't understand the benefits of that.
Renderer-agnostic is nice, actually, when you need to support lots of different browsers.
Some mobile browsers can't do WebGL as fast as they do Canvas, for instance. Other browsers will have a huge speed advantage with WebGL.
I'm not sure if any are faster with SVG, or the relative performance between SVG and canvas. But being able to do some test renders quickly in all three modes should allow you to select the fastest for a particular browser.
Game developers are better off with a game-oriented library, IMO. Even if you used something like Two.JS to do your rendering, there are a lot of things still useful in a game library to justify using it -- and most games will need more than geometric figures.
I love SVG support because it means you can render something in vector art in the browser which is also downloadable as a file by the user. Drawing stuff in the browser which is then stuck there is cute but lacks an important layer of interoperability with the rest of the computing ecosystem. So here we appear to get the best of all worlds: render to whatever is fastest in the browser but get automatic "export as SVG" for free.
I don't know what the real use case is, but I know that it's been awesome as a simple graphics API to teach programming to kids.
A while back I used Choc (http://www.fullstack.io/choc/) to teach JavaScript to a high school class. A lot of Two's competitors have APIs that take into account things like performance and extensibility, but are harder to explain because of it. It was great to have a simple API that got out of the way and allowed me to teach things like if statements, for loops and functions.
The author of two.js uses it for interactive art, like Patatap. It's great for creating fun motion design easily. I worked with him on a project where a live drummer plays drums and triggers sounds and shapes projected behind him: http://thecreatorsproject.vice.com/blog/introducing-drumpant...
It would be good if you wanted to make some content that has smooth animations that renders in all different browsers (i.e animated greeting cards, animated presentations, or animated websites). Basically anything that you could do in Flash 2D, you could also do with this.
Example: makemake.io (although PIXI.js is used in this case)
Yes! This is because when a shape is first created the WebGL Renderer draws the shape as a texture in Canvas2d and then uploads that texture to GL. The operations "Vertices" and "Scale" force each shape to be redrawn so there are a lot of textures being uploaded and deleted every frame this scenario. If you keep things to translation / rotation you can make the WebGL renderer push wayyyy more shapes than the other 2 renderers.
I'm currently developing a way to "cache" textures that don't change much so if you had a Two.Group that doesn't change much you can turn that into 1 texture. This will greatly increase performance as well. Thanks for checking it out!
Why don't you draw directly your vertices in gl instead of create a tex ? And you could use optimisation of culling to be faster. (drawing object : front to back)
Because the eng team that implements WebGL on Chrome recommended this way. I have an implementation as you're describing as the first tag of Two.js. It actually was a 2D drawing API for Three.js initially..!
I don't see anyway of working with textures at this point, am I wrong? Part of what I find interesting of working with Paper.js is the ability to render to a texture, and keep piling on stuff if necessary. I haven't tried the performance that would bring, but from what I understand it could be great.
As someone using D3.js a lot (even for a puzzle game) - what is the benefit of using Two.js? Jumping between SVG and Canvas? (But then, is it worth the price of reducing possibilities to circles and squares?)
You can do quite a bit with "circles and squares". Two.js focuses on Path drawing and has robust SVG interpretation for complex vector shapes.
I've found the portability to be fantastic. For instance http://patatap.com runs svg on iOS and canvas on Android. Two.js makes it simple to run either on the fly.
It is! I work on the dev branch and other branches when I'm making new changes. EDIT: I mostly use the library though (I use it everyday) rather than constantly develop new features.
How can someone who voices genuine concerns be a troll ?
I was actually interested in this framework. Right now I'm torn between pixi.js and easel.js , this seemed like a viable alternative.
But before I start to invest time in a technology, I want to know if it's still alive.
This project is definitely not finished (text rendering), far from polished (slow webgl implementation, see this thread) and has not been improved in half a year.
Sorry, but stuff like this just makes me angry. The javascript world is full of throwaway projects that die after a few months/years. At the same time there are true gems with really elegant code. Easel, Pixi, SnapSvg, they are amazing. Advertisement for a project like this is unfair and spreads confusion.
If you need help, if you look for contributors, just say so. But don't pretend that your code is alive when it's actually cold legacy code.
Self-entitled much? If the library doesn't suit your needs, just move on. There's no need to throw a tantrum about how a framework isn't tailored to your exact specifications, and how people aren't working hard enough so you can "invest" your oh-so-precious time in their unpaid effort.
An alternative library that is Canvas only but works well with input is ZRender[0]. Sadly the docs have not been translated to English (lingua franca of open source libs or software in general?) and I think that affects adoption.
In order to get helpful results, we're gonna have to pick some semi-arbitrary epsilon. Still, my problem domain might require a different epsilon than they expect; even if they have a default, the API should allow me to specify my own choice of epsilon.
While we're here, the article you linked recommends equality comparison w.r.t. "the maximum number of possible floating-point values between the two values".
Any idea on how to go about this in JavaScript? The binary representation of the float isn't as easy to come by (compared to C, for example), but I wonder if you couldn't get a decent approximation with Math.log2.
You can do this pretty easily with SVG, assuming your browser supports SVG, and your “caligraphic stroke” means you want the envelope of an ellipse translated along the path.
Or do you need the precise bezier-curves for the stroke outline? For that you need to do some computation.
I guess it would be something along the lines of this quote from http://farukat.es/journal/2011/02/528-modern-browser: "A modern browser is any browser that: successfully renders a site that you just built using web standards, testing only in your browser of choice along the way, with all the essentials functioning well; without you having written any browser-specific hacks, forks or workarounds; and shows great performance as you navigate it."
Why self-updating? Is my version of Firefox non-"modern" simply because I install and update it through my operating system's package management system?
In general as regards SVG [and canvas in this case], not IE <=8 or Android <= 2.4, and some caveats (eg will need careful testing, as some JS/DOM APIs or rendering optimisations may not be present) with earlier versions of FF/Chrome/Safari & IE9/10
what about in a year? i bet you would list different browsers and versions. my point is, "modern browser" doesn't mean anything and it change as time passes
True, it should specify where support drops off really, it's not as if there aren't tools to automate the JS testing part of it if the time isn't there to thoroughly manually check. I've think maybe spent too much time assessing JS libraries & frontend stuff; after a while when you see 'modern browser' you mentally tick off where it's likely to be functional and accept/discount the guessed tradeoffs (maybe a bad habit)
People keep reimplementing the same thing to the same "80%" completion level so they look good to employers, but the software is abandoned quickly once it has served its purpose as a personal branding tool.
I don't think this is something unique to the Javascript world people make sightly different eyeglasses, plates, houses, frameworks, libraries, programming languages, etc.
Awesome...but. No text? That suddenly wipes out my use case (data viz). I was super encouraged reading this post, multiple renderers including canvas / webgl (so I assume speed - unlike D3), smart, clean, indeed creative looking logo/site...suggests the author has taste...but no text kills this for me. I see no obvious use case for animated 2d that does not do textures (personally happy to do without) but also does not do text.
Unfortunately, this is a library authored and maintain by one person, me. I'd love to get to text at some point, but until then you'll have to stick with DOM. Also, depending on your renderer you have full access to SVG, Canvas, and WebGL so you can write text with those APIs...
These projects have had multi-million uniques throughout their existence. 3 other large scale projects coming out later this year that use Two.js..! And these are projects just made by me :P
Text is actually pretty tricky in WebGL. Lots of ways to do it, all very dependent on your application. I think it would be better to keep it out of the library but allow plugins/etc to compose easily with the rest of two.js.
