Interesting, I haven't seen that format before

Does this pixi.js project have some test cases for their hex conversion? Like, how does it handle numbers with > 6 digits?

There should also be a variation in .toString() for the "number" case that calls .toNumber()

Pixi uses the numbers internally for the GPU. There's a one-to-one mapping to string hex. e.g 0x0 === "#000000", so I don't think there's really any need for tests.
I didn't add a "number" format, I just converted it to an rgb object, since that was the fastest conversion, so I guess there's no need for a "number" case in .toString() ?

I didn't add a "number" format, I just converted it to an rgb object, since that was the fastest conversion, so I guess there's no need for a "number" case in .toString() ?

It looks like there was a toNumber function added to the prototype. Usually I have added a matching toString() definition for each of the to* functions added to the prototype but I guess it isn't really necessary for this

Pixi uses the numbers internally for the GPU. There's a one-to-one mapping to string hex. e.g 0x0 === "#000000", so I don't think there's really any need for tests.

So 0xffffffffffff000000 just ends up becoming #000000? What about -0x00ff00? Does it depend on the GPU?

Not sure about the big one. 0x00ff00 just becomes 0xff00 which is
interpreted as green. Doesn't depend on gpu as it's using webgl which is
standard across architectures.

On 2015年8月11日 18:00 Brian Grinstead notifications@github.com wrote:

Pixi uses the numbers internally for the GPU. There's a one-to-one mapping
to string hex. e.g 0x0 === "#000000", so I don't think there's really any
need for tests.

So 0xffffffffffff000000 just ends up becoming #000000? What about
-0x00ff00? Does it depend on the GPU?

—
Reply to this email directly or view it on GitHub
#98 (comment).

0x00ff00 just becomes 0xff00 which is interpreted as green

I had a negative in front of it :). So, -0x00ff00.

I'm not really sure. Maybe ultraviolet?! ;-)
It probably just comes out as black which is what happens if it's NaN

On 2015年8月11日 22:21 Brian Grinstead notifications@github.com wrote:

0x00ff00 just becomes 0xff00 which is interpreted as green

I had a negative in front of it :). So, -0x00ff00.

—
Reply to this email directly or view it on GitHub
#98 (comment).

did u decide on this PR ?

On Wed, Aug 12, 2015 at 7:38 AM Jonah Fox jonahfox@gmail.com wrote:

I'm not really sure. Maybe ultraviolet?! ;-)
It probably just comes out as black which is what happens if it's NaN

On 2015年8月11日 22:21 Brian Grinstead notifications@github.com
wrote:

0x00ff00 just becomes 0xff00 which is interpreted as green

I had a negative in front of it :). So, -0x00ff00.

—
Reply to this email directly or view it on GitHub
#98 (comment).

I would love to see this merged in. It's very useful when using libraries like pixi.js

Sorry, for the slow response. This pixi.js library is the only place I've seen this format used so far, so I'm hesitant to add support for it into the main library.

Maybe what we need is some kind of extension API where someone could register id, shouldHandleInput(input) -> bool, toRgb(input) -> {r,g,b,a} and toString({r,g,b,a}) -> string then the lib could loop through extensions and send tinycolor(0xaabbcc) into the toRgb method if shouldHandleInput is true. Then when tinycolor(0xaabbcc).toString("number") is called it would defer to the extension's method.

I would find this useful, either built in or as an extension.

For now, I have been passing colours through pixi's utility functions for converting between hex and rgb/string.

https://github.com/pixijs/pixi.js/blob/master/src/core/utils/index.js#L24-L65