Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.javascript > #14645 > unrolled thread
| Started by | justaguy <lichunshen84@gmail.com> |
|---|---|
| First post | 2012-06-24 04:31 -0700 |
| Last post | 2012-06-27 17:57 +0200 |
| Articles | 14 — 8 participants |
Back to article view | Back to comp.lang.javascript
Detect user graphics card? justaguy <lichunshen84@gmail.com> - 2012-06-24 04:31 -0700
Re: Detect user graphics card? Gregor Kofler <usenet@gregorkofler.com> - 2012-06-24 14:30 +0200
Re: Detect user graphics card? justaguy <lichunshen84@gmail.com> - 2012-06-24 07:43 -0700
Re: Detect user graphics card? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-06-25 05:14 +0200
Re: Detect user graphics card? justaguy <lichunshen84@gmail.com> - 2012-06-24 21:01 -0700
Re: Detect user graphics card? Stefan Weiss <krewecherl@gmail.com> - 2012-06-26 13:27 +0200
Re: Detect user graphics card? justaguy <lichunshen84@gmail.com> - 2012-06-26 12:54 -0700
Re: Detect user graphics card? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-06-26 22:38 +0200
Re: Detect user graphics card? Stefan Weiss <krewecherl@gmail.com> - 2012-06-27 01:05 +0200
Re: Detect user graphics card? Scott Sauyet <scott.sauyet@gmail.com> - 2012-06-27 07:07 -0700
Re: Detect user graphics card? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2012-06-29 16:41 -0700
Compute web-safe colors (was: Detect user graphics card?) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-06-30 10:40 +0200
Re: Detect user graphics card? Dr J R Stockton <reply1226@merlyn.demon.co.uk.not.invalid> - 2012-06-27 19:44 +0100
Re: Detect user graphics card? Arno Welzel <usenet@arnowelzel.de> - 2012-06-27 17:57 +0200
| From | justaguy <lichunshen84@gmail.com> |
|---|---|
| Date | 2012-06-24 04:31 -0700 |
| Subject | Detect user graphics card? |
| Message-ID | <e297bfd5-2f14-4f87-b6b4-92dc73c8b83d@r3g2000yqh.googlegroups.com> |
Hi guys, I have an iframe which uses the #BDD3FF background color to make it more appealing, however, recently I realize on some low end laptops this background color looks deep blue (bad), so, I wonder if there's a way to detect the user's graphics card via a web browser (since it's a web app) so as to provide appropriate background color. Many thanks
[toc] | [next] | [standalone]
| From | Gregor Kofler <usenet@gregorkofler.com> |
|---|---|
| Date | 2012-06-24 14:30 +0200 |
| Message-ID | <js719u$7j2$1@dont-email.me> |
| In reply to | #14645 |
Am 2012-06-24 13:31, justaguy meinte: > Hi guys, > > I have an iframe which uses the #BDD3FF background color to make it > more appealing, however, recently I realize on some low end laptops > this background color looks deep blue (bad), so, I wonder if there's > a > way to detect the user's graphics card via a web browser (since it's > a > web app) so as to provide appropriate background color. No. And it wouldn't help, since the user could still use a custom color profile or have changed the default settings of his display. Gregor
[toc] | [prev] | [next] | [standalone]
| From | justaguy <lichunshen84@gmail.com> |
|---|---|
| Date | 2012-06-24 07:43 -0700 |
| Message-ID | <80b62a11-0afd-4033-b222-edc3587ebe9c@f16g2000yqg.googlegroups.com> |
| In reply to | #14646 |
On Jun 24, 8:30 am, Gregor Kofler <use...@gregorkofler.com> wrote: > Am 2012-06-24 13:31, justaguy meinte: > > > Hi guys, > > > I have an iframe which uses the #BDD3FF background color to make it > > more appealing, however, recently I realize on some low end laptops > > this background color looks deep blue (bad), so, I wonder if there's > > a > > way to detect the user's graphics card via a web browser (since it's > > a > > web app) so as to provide appropriate background color. > > No. And it wouldn't help, since the user could still use a custom color > profile or have changed the default settings of his display. > > Gregor Thanks for this part, "No.". With regard to the following comment, " And it wouldn't help, since the user could still use a custom color > profile or have changed the default settings of his display.", that's up to them now. So, it looks like we have only two options left: a) keep this color at the expense of poor display due to lesser quality graphics card b) use a lesser rich color, that is, lower to the 'web safe color'. But neither is a good solution...
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2012-06-25 05:14 +0200 |
| Message-ID | <4454122.7EdHYbU6jS@PointedEars.de> |
| In reply to | #14646 |
Gregor Kofler wrote:
> Am 2012-06-24 13:31, justaguy meinte:
>> I have an iframe which uses the #BDD3FF background color to make it
>> more appealing, however, recently I realize on some low end laptops
>> this background color looks deep blue (bad), so, I wonder if there's
>> a way to detect the user's graphics card via a web browser (since it's
>> a web app) so as to provide appropriate background color.
>
> No. And it wouldn't help, since the user could still use a custom color
> profile or have changed the default settings of his display.
There is the host object referred to by the host-defined `screen' property
of the Global Object or window host object, which has a `pixelDepth'
property in more recent DOM implementations to indicate the number of bits
available for the color value of a pixel. It can be used to work around
this issue, but it may not be reliable:
<https://developer.mozilla.org/en/DOM/window.screen.pixelDepth>
The best solution – if the CD allows it – is to use what I call True Web-
safe Colors (`#000', `#003', …, `#00f`, …, `#030`, …, `#03f`, …, `#fff').
See also: <http://www.w3.org/TR/css3-color/#numerical>.
JSX:color.js [1] defines jsx.dom.css.Color.prototype.getWebSafe() which
computes the nearest Web-safe color for a given color. It can be used as
follows:
/* Include a `script' element for color.js and dependencies */
var myColor = new jsx.dom.css.Color("#BDD3FF");
var mySafeColor = myColor.getWebSafe();
console.log(mySafeColor);
jsx.dom.css.Color instances inherit a toString() method (equivalent to the
toRGBAString() method) that returns the CSS3 RGBA notation for the color
value. Therefore, references can be used verbatim in CSS scripting:
element.style.color = mySafeColor;
However, they also inherit toHex(), toRGBString(), and toJSON() methods, for
less advanced CSS implementations and other purposes.
jsx.dom.css.Color.prototype.toHex() returns the short notation if all quads
of each color value component are equal to the other quad (as recommended by
the CSS Specifications); it requires jsx.string.leadingZero() which we have
discussed yesterday.
PointedEars
___________
[1]
<http://PointedEars.de/websvn/filedetails.php?repname=JSX&path=%2Ftrunk%2Fdom%2Fcss%2Fcolor.js>
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)
[toc] | [prev] | [next] | [standalone]
| From | justaguy <lichunshen84@gmail.com> |
|---|---|
| Date | 2012-06-24 21:01 -0700 |
| Message-ID | <a25e8ded-821f-476a-a14f-63d93b14c295@r3g2000yqh.googlegroups.com> |
| In reply to | #14652 |
On Jun 24, 11:14 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> Gregor Kofler wrote:
> > Am 2012-06-24 13:31, justaguy meinte:
> >> I have an iframe which uses the #BDD3FF background color to make it
> >> more appealing, however, recently I realize on some low end laptops
> >> this background color looks deep blue (bad), so, I wonder if there's
> >> a way to detect the user's graphics card via a web browser (since it's
> >> a web app) so as to provide appropriate background color.
>
> > No. And it wouldn't help, since the user could still use a custom color
> > profile or have changed the default settings of his display.
>
> There is the host object referred to by the host-defined `screen' property
> of the Global Object or window host object, which has a `pixelDepth'
> property in more recent DOM implementations to indicate the number of bits
> available for the color value of a pixel. It can be used to work around
> this issue, but it may not be reliable:
>
> <https://developer.mozilla.org/en/DOM/window.screen.pixelDepth>
>
> The best solution – if the CD allows it – is to use what I call True Web-
> safe Colors (`#000', `#003', …, `#00f`, …, `#030`, …, `#03f`, …, `#fff').
> See also: <http://www.w3.org/TR/css3-color/#numerical>.
>
> JSX:color.js [1] defines jsx.dom.css.Color.prototype.getWebSafe() which
> computes the nearest Web-safe color for a given color. It can be used as
> follows:
>
> /* Include a `script' element for color.js and dependencies */
>
> var myColor = new jsx.dom.css.Color("#BDD3FF");
> var mySafeColor = myColor.getWebSafe();
> console.log(mySafeColor);
>
> jsx.dom.css.Color instances inherit a toString() method (equivalent to the
> toRGBAString() method) that returns the CSS3 RGBA notation for the color
> value. Therefore, references can be used verbatim in CSS scripting:
>
> element.style.color = mySafeColor;
>
> However, they also inherit toHex(), toRGBString(), and toJSON() methods, for
> less advanced CSS implementations and other purposes.
> jsx.dom.css.Color.prototype.toHex() returns the short notation if all quads
> of each color value component are equal to the other quad (as recommended by
> the CSS Specifications); it requires jsx.string.leadingZero() which we have
> discussed yesterday.
>
> PointedEars
> ___________
> [1]
> <http://PointedEars.de/websvn/filedetails.php?repname=JSX&path=%2Ftrun...>
> --
> Danny Goodman's books are out of date and teach practices that are
> positively harmful for cross-browser scripting.
> -- Richard Cornford, cljs, <cife6q$253$1$8300d...@news.demon.co.uk> (2004)
This is very helpful, thank you very much, and I'll check it tomorrow.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Weiss <krewecherl@gmail.com> |
|---|---|
| Date | 2012-06-26 13:27 +0200 |
| Message-ID | <jsc6bu$o4k$1@news.albasani.net> |
| In reply to | #14652 |
On 2012-06-25 05:14, Thomas 'PointedEars' Lahn wrote:
> JSX:color.js [1] defines jsx.dom.css.Color.prototype.getWebSafe() which
> computes the nearest Web-safe color for a given color.
...
> [1]
> <http://PointedEars.de/websvn/filedetails.php?repname=JSX&path=%2Ftrunk%2Fdom%2Fcss%2Fcolor.js>
Interesting.
As an aside, this function -
function getNearestSafeValue (value)
{
if (value >= 0xFF)
{
return 0xFF;
}
if (value <= 0)
{
return 0;
}
for (var safeValues = [0, 0x33, 0x66, 0x99, 0xCC, 0xFF],
i = safeValues.length - 1;
i--;)
{
var item = safeValues[i];
if (value >= item)
{
if (value == item)
{
return value;
}
var nextItem = safeValues[i + 1];
if (value - item < nextItem - value)
{
return item;
}
return nextItem;
}
}
return -1;
}
- could be simplified to:
function getNearestSafeValue (n) {
if (n >= 0xFF) {
return 0xFF;
}
if (n <= 0) {
return 0;
}
return Math.round(n / 0x33) * 0x33;
}
Or even in a single line (although less readable):
function getNearestSafeValue (n) {
return n >= 0xFF ? 0xFF : n <= 0 ? 0 : Math.round(n / 0x33) * 0x33;
}
A half-hearted benchmark indicates that the last version could be
between 2x faster (Chrome, Opera) and 5x faster (Firefox) than the original.
- stefan
[toc] | [prev] | [next] | [standalone]
| From | justaguy <lichunshen84@gmail.com> |
|---|---|
| Date | 2012-06-26 12:54 -0700 |
| Message-ID | <8af7604e-7021-447c-8911-746a5478d1c0@j10g2000yqd.googlegroups.com> |
| In reply to | #14666 |
On Jun 26, 7:27 am, Stefan Weiss <krewech...@gmail.com> wrote:
> On 2012-06-25 05:14, Thomas 'PointedEars' Lahn wrote:
>
> > JSX:color.js [1] defines jsx.dom.css.Color.prototype.getWebSafe() which
> > computes the nearest Web-safe color for a given color.
> ...
> > [1]
> > <http://PointedEars.de/websvn/filedetails.php?repname=JSX&path=%2Ftrun...>
>
> Interesting.
>
> As an aside, this function -
>
> function getNearestSafeValue (value)
> {
> if (value >= 0xFF)
> {
> return 0xFF;
> }
>
> if (value <= 0)
> {
> return 0;
> }
>
> for (var safeValues = [0, 0x33, 0x66, 0x99, 0xCC, 0xFF],
> i = safeValues.length - 1;
> i--;)
> {
> var item = safeValues[i];
>
> if (value >= item)
> {
> if (value == item)
> {
> return value;
> }
>
> var nextItem = safeValues[i + 1];
> if (value - item < nextItem - value)
> {
> return item;
> }
>
> return nextItem;
> }
> }
> return -1;
> }
>
> - could be simplified to:
>
> function getNearestSafeValue (n) {
> if (n >= 0xFF) {
> return 0xFF;
> }
> if (n <= 0) {
> return 0;
> }
> return Math.round(n / 0x33) * 0x33;
> }
>
> Or even in a single line (although less readable):
>
> function getNearestSafeValue (n) {
> return n >= 0xFF ? 0xFF : n <= 0 ? 0 : Math.round(n / 0x33) * 0x33;
> }
>
> A half-hearted benchmark indicates that the last version could be
> between 2x faster (Chrome, Opera) and 5x faster (Firefox) than the original.
>
> - stefan
wow, that's amazing.
"A half-hearted benchmark indicates that the last version could be
between 2x faster (Chrome, Opera) and 5x faster (Firefox) than the
original.
"
You're right.
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2012-06-26 22:38 +0200 |
| Message-ID | <2493601.R5VuAm1OKa@PointedEars.de> |
| In reply to | #14666 |
Stefan Weiss wrote:
> On 2012-06-25 05:14, Thomas 'PointedEars' Lahn wrote:
>> JSX:color.js [1] defines jsx.dom.css.Color.prototype.getWebSafe() which
>> computes the nearest Web-safe color for a given color.
> ...
>> [1]
>>
<http://PointedEars.de/websvn/filedetails.php?repname=JSX&path=%2Ftrunk%2Fdom%2Fcss%2Fcolor.js>
>
> Interesting.
Thanks.
> As an aside,
How is that an aside? :)
> this function -
>
> function getNearestSafeValue (value)
> {
> if (value >= 0xFF)
> {
> return 0xFF;
> }
>
> if (value <= 0)
> {
> return 0;
> }
>
> for (var safeValues = [0, 0x33, 0x66, 0x99, 0xCC, 0xFF],
> i = safeValues.length - 1;
> i--;)
> {
> var item = safeValues[i];
>
> if (value >= item)
> {
> if (value == item)
> {
> return value;
> }
>
> var nextItem = safeValues[i + 1];
> if (value - item < nextItem - value)
> {
> return item;
> }
>
> return nextItem;
> }
> }
> return -1;
> }
>
> - could be simplified to:
>
> function getNearestSafeValue (n) {
> if (n >= 0xFF) {
> return 0xFF;
> }
> if (n <= 0) {
> return 0;
> }
> return Math.round(n / 0x33) * 0x33;
> }
Yes, indeed. I never considered multiples. I think it could be further
optimized as follows:
function getNearestSafeValue (value)
{
if (value >= 0xFF)
{
return 0xFF;
}
if (value <= 0)
{
return 0;
}
if (value % 0x33 == 0)
{
return value;
}
return Math.round(value / 0x33) * 0x33;
}
If there are no objections or further suggestions, I will use that from now
on.
> Or even in a single line (although less readable):
>
> function getNearestSafeValue (n) {
> return n >= 0xFF ? 0xFF : n <= 0 ? 0 : Math.round(n / 0x33) * 0x33;
> }
No, thanks :)
> A half-hearted benchmark indicates that the last version could be
> between 2x faster (Chrome, Opera) and 5x faster (Firefox) than the
> original.
AISB, I am not that interested in benchmark results as they are treacherous.
I am more interested in provably working, efficient algorithms. You have
provided one. Thank you.
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
[toc] | [prev] | [next] | [standalone]
| From | Stefan Weiss <krewecherl@gmail.com> |
|---|---|
| Date | 2012-06-27 01:05 +0200 |
| Message-ID | <jsdf79$c8m$1@news.albasani.net> |
| In reply to | #14686 |
On 2012-06-26 22:38, Thomas 'PointedEars' Lahn wrote: > Stefan Weiss wrote: >> A half-hearted benchmark indicates that the last version could be >> between 2x faster (Chrome, Opera) and 5x faster (Firefox) than the >> original. > > AISB, I am not that interested in benchmark results as they are treacherous. > I am more interested in provably working, efficient algorithms. I only mentioned that because you seemed concerned about the overhead of function calls (in a different thread). I've also underestimated the efficiency of the current compilers before [1]. These days it's hard to predict which algorithms will be more efficient than others, let alone "provably efficient". It depends too much on which optimizations the engines make. Without intimate knowledge of the compiler internals, the best we can do is measure the alternatives; and the best we can derive from that is some rough idea of efficiency in the tested engines. Normally, I wouldn't have bothered, but a function which converts color values could actually be called many times in succession (for example, to manipulate an image-as-pixel-array). - stefan [1] There was a thread in this group a few months ago (I can't remember the exact title), where different alternatives for Math.floor() were mentioned. I would have bet a tidy sum that one of alternatives using binary operators would be fastest, and I would have lost. IIRC, Scott Sauyet did a benchmark and found out that Math.floor() is apparently very well optimized in some engines.
[toc] | [prev] | [next] | [standalone]
| From | Scott Sauyet <scott.sauyet@gmail.com> |
|---|---|
| Date | 2012-06-27 07:07 -0700 |
| Message-ID | <e92d4a85-797f-4581-9c12-9f84afb39dbd@f16g2000yqg.googlegroups.com> |
| In reply to | #14697 |
Stefan Weiss wrote:
> [1] There was a thread in this group a few months ago (I can't remember
> the exact title), where different alternatives for Math.floor() were
> mentioned. I would have bet a tidy sum that one of alternatives using
> binary operators would be fastest, and I would have lost. IIRC, Scott
> Sauyet did a benchmark and found out that Math.floor() is apparently
> very well optimized in some engines.
I was going to reply that your memory was playing tricks on you when I
stumbled across the post itself [1]:
Damn, I'm getting old!
It points to a JSPerf test [2], which compared these variations:
var f1 = function(n) {return Math.floor(n / 3);};
var f2 = function(n) {return (n - (n % 3)) / 3;};
var f3 = function(n) {return ~~(n / 3);};
var f4 = function(n) {return (n / 3) >> 0;};
var f5 = function(n) {return (n / 3) | 0;};
In none of the tests run was Math.floor the very fastest, but it was
usually not far from the top. And version f2 above, which was clearly
the fastest in Android 2.3.4 and was somewhat faster than the others
in Chrome 19, was by far the slowest in Firefox 10 and Firefox 12. So
-- as if we didn't already know -- choosing an algorithm for
performance can be a tricky proposition.
-- Scott
[1] <news:
67b160c3-9bd2-4872-9601-3125fff1c852@r13g2000vbg.googlegroups.com>,
<https://groups.google.com/group/comp.lang.javascript/msg/
c690aa2ccb9d8a8b>
[2] <http://jsperf.com/floor-alternatives>
[toc] | [prev] | [next] | [standalone]
| From | "Michael Haufe (TNO)" <tno@thenewobjective.com> |
|---|---|
| Date | 2012-06-29 16:41 -0700 |
| Message-ID | <5a0c9692-fe5e-446e-8d8f-558e233859c0@googlegroups.com> |
| In reply to | #14686 |
On Tuesday, June 26, 2012 3:38:44 PM UTC-5, Thomas 'PointedEars' Lahn wrote:
> Stefan Weiss wrote:
>
> > On 2012-06-25 05:14, Thomas 'PointedEars' Lahn wrote:
> >> JSX:color.js [1] defines jsx.dom.css.Color.prototype.getWebSafe() which
> >> computes the nearest Web-safe color for a given color.
> > ...
> >> [1]
> >>
> <http://PointedEars.de/websvn/filedetails.php?repname=JSX&path=%2Ftrunk%2Fdom%2Fcss%2Fcolor.js>
> >
> > Interesting.
>
> Thanks.
>
> > As an aside,
>
> How is that an aside? :)
>
> > this function -
> >
> > function getNearestSafeValue (value)
> > {
> > if (value >= 0xFF)
> > {
> > return 0xFF;
> > }
> >
> > if (value <= 0)
> > {
> > return 0;
> > }
> >
> > for (var safeValues = [0, 0x33, 0x66, 0x99, 0xCC, 0xFF],
> > i = safeValues.length - 1;
> > i--;)
> > {
> > var item = safeValues[i];
> >
> > if (value >= item)
> > {
> > if (value == item)
> > {
> > return value;
> > }
> >
> > var nextItem = safeValues[i + 1];
> > if (value - item < nextItem - value)
> > {
> > return item;
> > }
> >
> > return nextItem;
> > }
> > }
> > return -1;
> > }
> >
> > - could be simplified to:
> >
> > function getNearestSafeValue (n) {
> > if (n >= 0xFF) {
> > return 0xFF;
> > }
> > if (n <= 0) {
> > return 0;
> > }
> > return Math.round(n / 0x33) * 0x33;
> > }
>
> Yes, indeed. I never considered multiples. I think it could be further
> optimized as follows:
>
> function getNearestSafeValue (value)
> {
> if (value >= 0xFF)
> {
> return 0xFF;
> }
>
> if (value <= 0)
> {
> return 0;
> }
>
> if (value % 0x33 == 0)
> {
> return value;
> }
>
> return Math.round(value / 0x33) * 0x33;
> }
>
> If there are no objections or further suggestions, I will use that from now
> on.
>
> > Or even in a single line (although less readable):
> >
> > function getNearestSafeValue (n) {
> > return n >= 0xFF ? 0xFF : n <= 0 ? 0 : Math.round(n / 0x33) * 0x33;
> > }
>
> No, thanks :)
>
> > A half-hearted benchmark indicates that the last version could be
> > between 2x faster (Chrome, Opera) and 5x faster (Firefox) than the
> > original.
>
> AISB, I am not that interested in benchmark results as they are treacherous.
> I am more interested in provably working, efficient algorithms. You have
> provided one. Thank you.
Constraining values is used relatively often. Have you considered adding a Math.clamp method?
Example: <http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.mathhelper.clamp.aspx>
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2012-06-30 10:40 +0200 |
| Subject | Compute web-safe colors (was: Detect user graphics card?) |
| Message-ID | <2214440.4GTsLVHtI5@PointedEars.de> |
| In reply to | #14777 |
Michael Haufe (TNO) wrote:
> Thomas 'PointedEars' Lahn wrote:
^^^^^ ^^^^^
Pardon?
>> Stefan Weiss wrote:
>>> […]
>> […] I think it could be further
>> optimized as follows:
>>
>> function getNearestSafeValue (value)
>> {
>> if (value >= 0xFF)
>> {
>> return 0xFF;
>> }
>>
>> if (value <= 0)
>> {
>> return 0;
>> }
>>
>> if (value % 0x33 == 0)
>> {
>> return value;
>> }
>>
>> return Math.round(value / 0x33) * 0x33;
>> }
>>
>> If there are no objections or further suggestions, I will use that from
>> now on.
>>
>> […]
>> > A half-hearted benchmark indicates that the last version could be
>> > between 2x faster (Chrome, Opera) and 5x faster (Firefox) than the
>> > original.
>>
>> AISB, I am not that interested in benchmark results as they are
>> treacherous.
>> I am more interested in provably working, efficient algorithms. You have
>> provided one. Thank you.
Thank you for quoting this line, but try to trim to the *relevant* parts
next time.
And *please* do not Cc: me.
> Constraining values is used relatively often. Have you considered adding a
> Math.clamp method?
>
> Example:
> <http://msdn.microsoft.com/en-
us/library/microsoft.xna.framework.mathhelper.clamp.aspx>
Not yet (it would be jsx.math.clamp() then). Calling the method instead of
the `if' statements above would also introduce another dependency, and
probably reduce efficiency, both of which I try to avoid.
PointedEars
--
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
-- Richard Cornford, comp.lang.javascript, 2011-11-14
[toc] | [prev] | [next] | [standalone]
| From | Dr J R Stockton <reply1226@merlyn.demon.co.uk.not.invalid> |
|---|---|
| Date | 2012-06-27 19:44 +0100 |
| Message-ID | <xllzgjIFS16PFwDK@invalid.uk.co.demon.merlyn.invalid> |
| In reply to | #14666 |
In comp.lang.javascript message <jsc6bu$o4k$1@news.albasani.net>, Tue,
26 Jun 2012 13:27:58, Stefan Weiss <krewecherl@gmail.com> posted:
>Or even in a single line (although less readable):
>
> function getNearestSafeValue (n) {
> return n >= 0xFF ? 0xFF : n <= 0 ? 0 : Math.round(n / 0x33) * 0x33;
> }
>
>A half-hearted benchmark indicates that the last version could be
>between 2x faster (Chrome, Opera) and 5x faster (Firefox) than the original.
Without having tested it, I'd expect that Math.round(n / 0x33) could
usefully (if speed matters) be replaced by something like
( ( ( n+0x19) / 0x33 ) | 0 ) or
( ( ( n+0x1A) / 0x33 ) | 0 ) or
( ( (2*n+0x33) / 0x66 ) | 0 )
though it seems likely that at least one of those will round borderline
cases differently.
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk DOS 3.3, 6.20; WinXP.
Web <http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms and links.
PAS EXE TXT ZIP via <http://www.merlyn.demon.co.uk/programs/00index.htm>
My DOS <http://www.merlyn.demon.co.uk/batfiles.htm> - also batprogs.htm.
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2012-06-27 17:57 +0200 |
| Message-ID | <4FEB2D85.1000305@arnowelzel.de> |
| In reply to | #14645 |
justaguy, 24.06.2012 13:31: > I have an iframe which uses the #BDD3FF background color to make it > more appealing, however, recently I realize on some low end laptops > this background color looks deep blue (bad), so, I wonder if there's > a > way to detect the user's graphics card via a web browser (since it's > a > web app) so as to provide appropriate background color. No. You should to use a "websafe color", if you want to be sure that the color generally works in most environments: <http://www.colortools.net/color_chart_web-safe.html> -- Arno Welzel http://arnowelzel.de http://de-rec-fahrrad.de
[toc] | [prev] | [standalone]
Back to top | Article view | comp.lang.javascript
csiph-web