-
-
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" | |
] | |
} |
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
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.