部分出于乐趣，部分出于我的设计理念，我正在尝试将动画 gif 转换为纯动画 CSS。
它几乎可以正常工作，但我遇到了一个障碍，我不确定是什么导致了我的问题，或者我该如何解决它。不幸的是，我怀疑我只是遇到了技术的限制。
我一直用于测试的 gif 是这样的:https://us.v-cdn.net/5018289/uploads/editor/yj/lcdjneh1yoxv.gif
至于实际的 CSS，我一直在尝试实现这里的方法(动画框阴影属性)，因为它看起来是最可行的: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 - 但到目前为止还没有解决任何问题问题。
正如我所说，我担心我只是遇到了技术本身的限制。任何想法可能是什么问题，我是否可以解决它？
编辑:这个特定动画的完整源代码可以在这两个要点中找到。由于 CSS 文件的大小，我选择了 Gists。
最佳答案
正确答案
最后，都是animation-timing-function的功劳。 steps() 函数中的第一个参数不是关键帧数(或循环中的步数)，而是关键帧之间渲染的步数。
所以将它更改为 steps(1,end) 修复了它，因为浏览器不再需要计算中间帧(由于大量的 box-shadow 它显然失败了 值 - 每个像素基本上有 1 个值 - 邪恶的技术，顺便说一句)。
查看它的工作情况:https://jsfiddle.net/websiter/wnrxmapu/2/
上一个答案::(部分不正确，导致上面的答案正确 - 我保留它是因为它可能对其他人调试类似动画有帮助):
最初我认为您的导出工具...完全错误。
为什么？因为将 animation-duration 从 1s 增加到 100s 产生了 this result .
明显的结论是你的中间框架有问题。
但是，我单独测试了它们中的每一个，令我惊讶的是，它们呈现正确。
由此得出的结论是，每个关键帧的 box-shadow 计算数量有限，并且执行了某种聚类算法。
这是有道理的，因为我们在这里讨论的是 box-shadow，在 99.999999999% 的情况下(基本上所有除了你的) 不必必须准确。它应该(而且显然是)近似有利于渲染速度，原因很明显:我们正在谈论用户体验和“感觉”。大多数用户都不是技术人员，他们只是希望在任何和所有条件下都能流畅滚动。
我得出的结论是，在尽最大努力优化您的代码，将其减少到初始大小的一半以下之后，每个关键帧允许的计算量必须有限制:https://jsfiddle.net/websiter/wnrxmapu/1/
我找不到任何关于 box-shadow 的像素聚类技术的 Material ，而且我认为网上提供的资料不多 - 这应该是 secret 信息。
但是，恕我直言，除了吹牛的权利，与 gif 或 svg 相比，我认为您的技术在渲染性能方面没有机会。强调“恕我直言”。如果您坚持要完成此操作，则可能需要将图像切分并检查允许的计算限制是针对每个元素还是针对每个页面。
但我不会抱太大希望。就像您的代码所揭示的优化一样，它使 CSS 快如闪电。如果一定要准确，就不会这么快了。
关于html - CSS 盒子阴影动画像素艺术闪烁，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/50559036/