-
-
Save jed/983535 to your computer and use it in GitHub Desktop.
| function( | |
| a, // red, as a number from 0 to 255 | |
| b, // green, as a number from 0 to 255 | |
| c // blue, as a number from 0 to 255 | |
| ){ | |
| return "#" + // return a number sign, and | |
| ( // combine the octets into a 32-bit integer as: [1][a][b][c] | |
| ( // operator precedence is (+) > (<<) > (|) | |
| 256 // [1][0] | |
| + a // [1][a] | |
| << 8 // [1][a][0] | |
| | b // [1][a][b] | |
| ) | |
| << 8 // [1][a][b][0] | |
| | c // [1][a][b][c] | |
| ) | |
| .toString(16) // then serialize to a hex string, and | |
| .slice(1) // remove the 1 to get the number with 0s intact. | |
| } |
| function(a,b,c){return"#"+((256+a<<8|b)<<8|c).toString(16).slice(1)} |
| DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE | |
| Version 2, December 2004 | |
| Copyright (C) 2011 Jed Schmidt <http://jed.is> | |
| Everyone is permitted to copy and distribute verbatim or modified | |
| copies of this license document, and changing it is allowed as long | |
| as the name is changed. | |
| DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE | |
| TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION | |
| 0. You just DO WHAT THE FUCK YOU WANT TO. |
| { | |
| "name": "rgb2hex", | |
| "description": "Converts RGB colors to a hexadecimal string.", | |
| "keywords": [ | |
| "color", | |
| "css", | |
| "hex", | |
| "rgb" | |
| ] | |
| } |
also, i checked MDC again, and since << is higher than | we can get rid of a bunch of parens.
You can shave one byte by reorganizing the octet combination as:
function(a,b,c){return"#"+((256+a<<8|b)<<8|c).toString(16).slice(1)}
@jed: Re: your comment on checking MDC for operator precedence – when in doubt, you could always use @qfox’s online ES Parser tool: http://esparser.qfox.nl/
@atesgoral: wow, done. the original is much more readable, unfortunately... would you mind taking a crack at the annotation?
@mathiasbynens: i still haven't been able to grok that tool fully. @qfox is really insane: his last quiz made me feel like a total JS n00b.
i still haven't been able to grok that tool fully.
Me neither, but if you just enter e.g. a<<16+1<<24 and hit the “Parse” button, it immediately becomes clear which operators take precedence.
Under “Pruning” you can also enable “flatten parse tree (replace nodes with single child by that child)”, which really helps if you’re just testing for precedence.
Here’s a live example: http://esparser.qfox.nl/#runnow:on,no-single-parents:on,code:a%3C%3C16+1%3C%3C24
Pro tip: add http://esparser.qfox.nl/#runnow:on,no-single-parents:on,code:%s to your custom search engines / location bar shortcuts in your browser of choice.
heh, i think you and i have different meanings for the word 'immediately'... the above helps a lot, but looking at the mdc chart is usually a lot faster for me.
@jed: Instead of forking, I'll just add the annotation here:
return "#" + // return a number sign, plus
(
// Combine the octets into a 32-bit integer as:
// [1][a][b][c]
// Operator precedence is (+) > (<<) > (|)
(
256 // [1][0]
+ a // [1][a]
<< 8 // [1][a][0]
| b // [1][a][b]
)
<< 8 // [1][a][b][0]
| c // [1][a][b][c]
)
thanks, @atesgoral. you're on a total roll!
Haven't perf tested this, but the bitwise ops should be fast. Great stuff here.
None of these rgbToHex functions should ever be a bottleneck. But I wanted to test these to see anyway. Just to see.
The original tests use inline code, but those I've added use functions. That's a lousy comparison for a test case. Should all of them use functions, or does it make sense to use inline code for JsPerf?
Should all of them use functions, or does it make sense to use inline code for JsPerf?
IMHO it would make more sense to declare the functions in the preparation/setup code section on jsPerf, and then have the actual tests themselves only consist of a single function call. That seems like the fairest comparison. Something like this: http://jsperf.com/rgbtohex/6
16777216could be shortened to1<<24.