颜色声明之间的性能差异?

Wes*_*rch 24 css performance

在CSS中,我们可以使用几种不同的方法来定义颜色:

  • 颜色词: red
  • 十六进制: #FF0000
  • 红色/绿色/蓝色通道: rgb(255, 0, 0)
  • 色相/饱和度/亮度: hsl(0, 100%, 50%)

我确实意识到使用命名颜色并不是一个好主意,因为不同的浏览器都有自己的想法aquamarine.

忽略alpha通道和浏览器支持,这四种方法之间在性能方面有什么不同吗?

如果我们试图从我们的CSS中挤出最后一点优化,哪一个是首选,如果有的话?颜色值是在内部转换为特定格式,还是其性能取决于其他任何内容(如使用哪个渲染代理或浏览器)?

如果可能,寻找"技术"答案,参考赞赏.

Cru*_*han 16

如果我们假设现代浏览器充分利用GPU,那么内部颜色表示将是RGB浮点数.忽略颜色名称 - 这可能只是十六进制的地图 - 我认为十六进制和通道将是最快的.毫无疑问HSB将是最慢的,因为从HSB到RGB的转换确实需要一些工作 - 大约50行C代码.

但是,我认为就CSS而言,这是一个完全无关紧要的问题.即使对于HSB到RGB,一种颜色的工作量也将是微不足道的.通过对此的支持,我有几个程序 - 包括那些在手机上运行的程序 - 在大型图像上以每像素级别进行颜色处理,我在做RGB-> HSB - >(某些操作) - > RGB.即使在ipad上执行此操作100,000次也只会导致几秒钟的延迟 - 所以在这个相对较慢的平台上,我认为您可以安全地假设典型的最坏情况转换需要少于0.0001秒.这是悲观的.

所以只需使用最简单的代码即可.

增加:支持不要担心这个选项.在内部,GPU会将颜色操作为浮点数组,因此用C表示

浮色[4];

或类似的东西.因此,对数字选项进行的唯一转换是一个简单的除以255.

另一方面,HSB到RGB的转换需要相当长的时间 - 我估计,从编写代码开始,大约需要10到20次操作.因此粗略地说,HSB相当慢,但现代GPU上的20次(甚至20,000次)操作并不值得担心 - 这是不可察觉的.

  • 我想有人会告诉我不要担心,我试图避开那些类型的评论.我对此也有好奇心,所以它并非完全不相关,而且必须存在准确,具体的答案,对吗?所以你是说Hex转换为RGB,那RGB可能是最快的吗?我同意颜色名称,我想我们可以假设它不是赢家:)感谢您分享您的经验. (3认同)
  • 为了清楚起见,我完全明白,性能差异超出了*琐碎,你真的不必说服我,但我有一个好奇的想法,这些东西是如何工作的,并希望了解更多.我没有在Google上找到任何信息,我认为这是一个利基话题.再次感谢您分享您的知识. (2认同)

nu *_*est 10

以下是结果,包括颜色名称,短十六进制,十六进制,rgb,rgba,hsl和hsla.你可以在这里自己运行测试.

性能测试结果

  • 该基准与问题有何关系?它表示 JavaScript 可以对值进行赋值和求值的频率。它没有说明实际渲染时间,是吗? (2认同)

Ken*_*ing 9

通常,css优化是关于最小化通过线路的字节数.十六进制颜色往往是最短的(在您的示例中,可以使用#f00代替#ff0000).

我意识到这并没有完全回答你提出的问题,但我还没有看到任何试图测量不同颜色表示如何影响渲染速度的浏览器测试.

  • 实际上不仅仅是字节数。不同的“字节”(函数)对性能有不同的影响。以模糊效果为例:字节数不多,但 CPU/GPU 非常密集。 (2认同)

clo*_*jas 6

我也对此感到好奇(这是星期五下午).这是一个用于各种CSS颜色方法的JSPerf:

http://jsperf.com/css-color-names-vs-hex-codes/18


s3c*_*s3c 5

我使用了其他人使用的jsperf.com中的相同工具,并为不同的颜色格式创建了自己的测试。然后我在 IE11、Edge17、FF64 和 Chrome71 上运行测试,并将所有结果收集到一个紧凑的 excel 电子表格中。

前三名是绿色,后三名是红色,最好和最差是粗体。

我不知道为什么 Chrome 如此倾向于命名颜色格式,但这让我用相同和不同的参数多次重复测试。结果保持不变。

您无法得出任何一种格式是绝对最好的结论性结果,但我的结论如下。

我将继续使用十六进制而不是命名,小写而不是大写,并在可能的情况下开始使用短而不是长的十六进制。

如果结果随着新版本的浏览器发生变化,请随时更新结果。