Question

部分用于测试，部分用于我的设计理念，我正在尝试将动画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 - 但到目前为止还没有解决问题。

正如我所说，我担心我只是对技术本身的限制。任何想法可能是什么问题，以及我是否可以解决它？

编辑：这个特定动画的完整源代码可以在这两个Gists中找到。由于CSS文件的大小，我选择了Gists。

Answer 1

正确答案

最后，完全是由于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的像素聚类技术的任何资料，而且我认为网上没有太多可用的东西-这应该是机密信息。

但是，恕我直言，除了吹牛的权利外，与gif或svg相比，我认为您的技术在渲染性能方面没有机会。强调“恕我直言” 。如果您坚持要完成此操作，则可能需要将图像切成薄片，并检查允许的计算限制是按元素还是按页。

~~但我不会寄希望于太。就像您的代码所揭示的那样，优化使CSS闪电般快速。如果必须准确，那就不会那么快。~~

CSS Box Shadow-Animated Pixel Art Flickering

1 个答案: