CSS盒子阴影-动画像素艺术闪烁

Question

CSS盒子阴影-动画像素艺术闪烁

6

为了一部分好玩，一部分是我有的设计想法，我正在尝试将一个动态gif转换成纯CSS动画。

它几乎快要成功了，但我遇到了一个问题，不确定是什么原因导致的，或者我该如何解决。我不幸地怀疑我只是碰到了技术的限制。

我用来测试的gif是这个：https://us.v-cdn.net/5018289/uploads/editor/yj/lcdjneh1yoxv.gif 至于实际的CSS，我一直在尝试实现这里的方法（动画box-shadow属性），因为它似乎是最可行的：https://codepen.io/andrewarchi/pen/OXEEgL

#ash::after {
  animation: ash-frames 0.4s steps(1) infinite;
}

@keyframes ash-frames {
    0% {box-shadow: 32px 8px #181818, 40px 8px #181818,...}
    ...
}

在给定的示例中，动画似乎相当流畅，所以我觉得值得一试。明显的区别是：我使用的gif有更多的帧和更多的像素。

快速概述一下我的CSS（我正在使用供应商标记等，这只是一个示例）：

.pixel-art-3940::after {
    animation: pixel-art-3940-frames 1s steps(5, end) infinite;
}

@keyframes pixel-art-3940-frames {
    0% {box-shadow: 112px 68px rgba(77, 69, 64, 1),...}
    16.666666666666668% {box-shadow:115px 65px rgba(77, 69, 64, 1),...}
    ...
}

动画似乎确实在工作，但是动画上有一种强烈的“闪烁”效果。请参见下文：

我已经尝试了在Chrome中解决“闪烁转换”的常规方法，比如将-webkit-backface-visibility设置为hidden，但到目前为止没有任何解决办法。就像我所说的，我担心这只是技术本身的限制。有什么想法可能是问题所在，以及我是否可以解决它？编辑：这个特定动画的完整源代码可以在这两个Gist中找到。我选择使用Gist是因为CSS文件的大小。

HTML: https://gist.githubusercontent.com/ChrGriffin/2f1f221143e24d3e39cad8e7369bc167/raw/16ea77d21aa79cf9da52fc3477a6773af41130f2/image.html（超文本标记语言）
CSS: https://gist.githubusercontent.com/ChrGriffin/7dcff0f119532ff37f68c01a8a22ecb5/raw/3e49d3dd0b7fa93aef6708750770d2616c53f682/image.css（层叠样式表）

- CGriffin

这个 CodePen 展示了一个看起来很好的 Pokemon 动画，你有你所询问的东西的代码放在哪里可以重现所展示的内容吗？ - Chris W.

@ChrisW。我已将完整源代码添加到问题中。 - CGriffin

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- tao · Accepted Answer

正确答案

最终，问题出在animation-timing-function上。在steps()函数中的第一个参数不是关键帧的数量（或循环中步数的数量），而是在关键帧之间呈现的步骤数。

因此将其更改为steps(1, end)可以解决问题，因为浏览器不再需要计算中间帧（由于box-shadow值过多而失败-每个像素基本上都有1个值 - 顺便说一句，这是一种非常棒的技术）

查看它的工作方式：https://jsfiddle.net/websiter/wnrxmapu/2/

以前的答案：（部分错误，导致正确答案 - 我保留它可能对其他调试类似动画的人有帮助）：

一开始我认为你的导出工具... 简直是错的。

为什么？因为将animation-duration从1s增加到100s会产生这个结果。

显然结论是你的中间帧有问题。

但是，我对每个中间帧进行了单独测试，并且出乎意料地它们都正确呈现了。

这导致结论是每个关键帧中box-shadow的计算次数受到限制，并执行某种聚类算法。

这很有道理，因为我们在谈论box-shadow，在99.999999999％的情况下（基本上是全部），不需要精确。它应该被近似，以获得更快速的渲染速度，原因显而易见：我们正在关心用户体验和“感觉”。大多数用户都不具备技术能力，他们只是期望在任何情况下都能流畅滚动。

在尝试优化您的代码后，我得出结论必须对每个关键帧允许的计算量进行限制，将其缩小至初始大小的不到一半：https://jsfiddle.net/websiter/wnrxmapu/1/

我无法找到任何像素聚类box-shadow技术的材料，我认为在线上没有太多可用的 - 这应该是机密信息。

然而，就我个人而言，除了炫耀之外，与gif或svg相比，我不认为你的技术在渲染性能方面有机会。重点强调"IMHO"。如果您坚持要完成此操作，可能需要将图像分割并检查允许计算的限制是每个元素还是每个页面。

但我不会抱太大的希望。正是像你的代码所揭示的优化使得CSS变得极快。如果它必须准确无误，它就不会那么快。