Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.javascript > #14645 > unrolled thread

Detect user graphics card?

Started byjustaguy <lichunshen84@gmail.com>
First post2012-06-24 04:31 -0700
Last post2012-06-27 17:57 +0200
Articles 14 — 8 participants

Back to article view | Back to comp.lang.javascript


Contents

  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

#14645 — Detect user graphics card?

Fromjustaguy <lichunshen84@gmail.com>
Date2012-06-24 04:31 -0700
SubjectDetect 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]


#14646

FromGregor Kofler <usenet@gregorkofler.com>
Date2012-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]


#14648

Fromjustaguy <lichunshen84@gmail.com>
Date2012-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]


#14652

FromThomas 'PointedEars' Lahn <PointedEars@web.de>
Date2012-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]


#14653

Fromjustaguy <lichunshen84@gmail.com>
Date2012-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]


#14666

FromStefan Weiss <krewecherl@gmail.com>
Date2012-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]


#14683

Fromjustaguy <lichunshen84@gmail.com>
Date2012-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]


#14686

FromThomas 'PointedEars' Lahn <PointedEars@web.de>
Date2012-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]


#14697

FromStefan Weiss <krewecherl@gmail.com>
Date2012-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]


#14707

FromScott Sauyet <scott.sauyet@gmail.com>
Date2012-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]


#14777

From"Michael Haufe (TNO)" <tno@thenewobjective.com>
Date2012-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 &#39;PointedEars&#39; 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]


#14780 — Compute web-safe colors (was: Detect user graphics card?)

FromThomas 'PointedEars' Lahn <PointedEars@web.de>
Date2012-06-30 10:40 +0200
SubjectCompute web-safe colors (was: Detect user graphics card?)
Message-ID<2214440.4GTsLVHtI5@PointedEars.de>
In reply to#14777
Michael Haufe (TNO) wrote:

> Thomas &#39;PointedEars&#39; 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]


#14731

FromDr J R Stockton <reply1226@merlyn.demon.co.uk.not.invalid>
Date2012-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]


#14714

FromArno Welzel <usenet@arnowelzel.de>
Date2012-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