Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Raphael.js 2.0 beta release is out - GitHub

github.com

Post reply on HN
Print view View original

11–19 of 19 posts

Re: Raphael.js 2.0 beta release is out - GitHub

#11

Post by netnichols »

danjwilson wrote: post #4
lamby wrote: post #2

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.

Re: Raphael.js 2.0 beta release is out - GitHub

#12

Post by grayrest »

pedrokost wrote: post #7

round = function (num) { return +num + (~~num === num) * .5; }; 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.

Re: Raphael.js 2.0 beta release is out - GitHub

#13

Post by euroclydon »

grayrest wrote: post #12
pedrokost wrote: post #7

round = function (num) { return +num + (~~num === num) * .5; }; 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 o…

Thanks. Anything quicker than parseFloat?

Re: Raphael.js 2.0 beta release is out - GitHub

#14

Post by grayrest »

euroclydon wrote: post #13
grayrest wrote: post #12

Earlier quoted context omitted.

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 o…

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.

Re: Raphael.js 2.0 beta release is out - GitHub

#16

Post by kreek »

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

Re: Raphael.js 2.0 beta release is out - GitHub

#17

Post by endtime »

euroclydon wrote: post #15
pedrokost wrote: post #7

round = function (num) { return +num + (~~num === num) * .5; }; What does ~~num do?

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

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.

Re: Raphael.js 2.0 beta release is out - GitHub

#18

Post by mryall »

endtime wrote: post #17
euroclydon wrote: post #15

Earlier quoted context omitted.

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

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.

Re: Raphael.js 2.0 beta release is out - GitHub

#19

Post by endtime »

mryall wrote: post #18
endtime wrote: post #17

Earlier quoted context omitted.

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…

Oh, cool, thanks for explaining that.
Post reply on HN