
Raphael.js 2.0 beta release is out - GitHub - bai
https://github.com/DmitryBaranovskiy/raphael/tree/2.0
======
lamby
Which is really and genuinely great, except the author is still releasing the
code in essentially impossible-to-review code drops:
[https://github.com/DmitryBaranovskiy/raphael/commit/164c349e...](https://github.com/DmitryBaranovskiy/raphael/commit/164c349e13326ce41eca13cb4318b5be52c8f002)

~~~
danjwilson
It's also difficult to contribute. Because of the one-commit-per-release
strategy, Pull Requests aren't accepted (though the changes normally end up in
the next release).

~~~
netnichols
I've had a one-line bug-fix pull request rejected with the answer of something
like "that's fixed in version 2". Well, I'm glad it's fixed in v2, but now I
have to maintain my own fork until v2 is released and is stable enough for
production use.

I have massive respect for Dmitry's pure abilities and the library as a whole,
but trying to contribute is pretty frustrating.

------
kreek
There's a list of changes on the Google group.
[http://groups.google.com/group/raphaeljs/browse_thread/threa...](http://groups.google.com/group/raphaeljs/browse_thread/thread/f76614f79da88478)

• New transformation API and implementation, dramatically faster and flexible
(full support for matrix transformations) • New animation API extension • Fix
for subpixel rendering in IE • New arrowhead attributes • Improved getBBox
calculation • Fix for HSB and HSL • Added viewBox support • New built-in event
system • and lots of tiny bug fixes

------
pedrokost
round = function (num) { return +num + (~~num === num) * .5; };

What does ~~num do?

~~~
grayrest
Bitwise operations coerce the value to a int32. If a value cannot be
reasonably coerced to an int (e.g. 'foo'), you get zero. It's basically the
same as parseInt(x,10) but is generally faster, you don't need to remember the
radix, and you don't get NaN. The downside is that trying to coerce numbers
outside int32 will give incorrect answers.

The other way to write it is 0|num which has the advantage of only applying
one bitwise op.

These tend to crop up most often in graphics oriented libraries.

~~~
euroclydon
Thanks. Anything quicker than parseFloat?

~~~
grayrest
You'd have to bench it, but the only thing I could think of that'd be faster
is the standard +num coercion that's also used in the code snippet.
Unfortunately, that does generate NaNs.

Edit: Double checked the spec (it's quite readable) and the main difference is
that + will coerce ignoring whitespace while parseFloat will ignore leading
whitespace and parse leading digits. E.g. var x = '1.23foo'; parseFloat(x) is
1.23; +x is NaN. Neither looks like it should be faster than the other.

