Raphael.js 2.0 beta release is out - GitHub(github.com)
github.com
Raphael.js 2.0 beta release is out - GitHub
https://github.com/DmitryBaranovskiy/raphael/tree/2.0
3 comments
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...
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).
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.
I have massive respect for Dmitry's pure abilities and the library as a whole, but trying to contribute is pretty frustrating.
Also, a ChangeLog would be great.
Or, for that matter, per-version documentation.
Or, for that matter, per-version documentation.
Yeah. I wish he knew about "Commit early, commit often"...
He does. Also, he doesn't like contributions that much because most of the contributions he gets are (his words) "bad". Dmitry is ultra talented, but some of his opinions are bound to shock a few developers. If interested, see this interview with him on The Changelog:
http://thechangelog.com/post/631899187/episode-0-2-5-rapha-l...
http://thechangelog.com/post/631899187/episode-0-2-5-rapha-l...
Thanks!
There's a list of changes on the Google group. http://groups.google.com/group/raphaeljs/browse_thread/threa...
• 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
• 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
round = function (num) {
return +num + (~~num === num) * .5;
};
What does ~~num do?
What does ~~num do?
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.
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.
Thanks. Anything quicker than parseFloat?
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.
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.
What exactly does this function do?
I tried it:
round("2.2") -> 2.2
round(2.2) -> 2.2
round("2.6") -> 2.6
round(2.6) -> 2.6
I tried it:
round("2.2") -> 2.2
round(2.2) -> 2.2
round("2.6") -> 2.6
round(2.6) -> 2.6
If num is an integer, it returns num + 0.5; otherwise it just returns num. I don't see why this is called 'round' or why it would be particularly useful behavior, so it's probably a bug.
I'm pretty sure it's to work around a difference in SVG and VML. In SVG, a one-pixel line rendered at an integral coordinate (like x=1) will render half-half on either side of that value, resulting in a blurry two-pixel-wide line. VML renders a one-pixel line in this case, automatically colouring the pixel(s) between x=1 and x=2.
Raphaël adds 0.5 to the values in SVG in order to make one-pixel-wide lines render as a single pixel instead of two.
Raphaël adds 0.5 to the values in SVG in order to make one-pixel-wide lines render as a single pixel instead of two.
Oh, cool, thanks for explaining that.
~ is bitwise NOT. For a number it returns the ones complement: ~N = -(N+1)
So ~~num I think would return the original value. The only reason I can see would be to coerce it into some kind of number type.
So ~~num I think would return the original value. The only reason I can see would be to coerce it into some kind of number type.
it will round toward zero