在 WebKit 中高效循环浏览大量固定位置图像的最佳方法是什么？

发布于 2024-12-21 13:29:42 字数 2116 浏览 5 评论 0原文

我目前正在为我的家人开发一个小网站。我想做的一件事是制作一个基本的定格动画视频。我可以组装它并将其上传到 Vimeo 或其他东西，但我认为这是一个只使用 HTML、CSS 和 Javascript 的绝佳机会。

我已经设置了所有样式，并且我的 JS 正在运行，等等，但它在 Chrome 和 Safari 中的表现很糟糕。有趣的是，它在 Firefox 中运行得很好，但我在 IE 中还不支持它。我希望每秒 8 到 12 帧播放音乐，因此我还没有费心去尝试。糟糕的表现远不止于此。目前，我在 Firefox 中获得了大约 3 fps（可以接受，但不是我想要的），在 Chrome 和 Safari 中，我获得了大约 .6795帧率。

运行 Chrome Profiler 时，我得到以下（相关）输出。

99.96%   99.96%     (program)
0.03%    0.03%      (garbage collector)
0.01%    0.01%      script.js:5:nextSlide

我以前从未使用过 Profiler，但我相信这向我表明，我的 JS 并不是对性能造成如此严重影响的原因。

我发布了测试页面，记录了您可以使用 Chrome 和 Firefox 访问的性能差异。

我还发现这似乎与循环的图像有关。骑自行车不同，更简单的图像似乎在 Chrome 和 Firefox 中都运行得很好，尽管 Chrome 仍然比 Firefox 更耗电。

作为至少这一结论的进一步证明，尽管这是完全不可接受的，但已证明此处，通过 转换-压缩 JPEG-质量 1。它们的循环效率要高得多，但质量当然很糟糕。

我已在 Chrome (16.0.912.63)、Safari (5.1.2 (6534.52.7))、WebKit nightly (Version 5.1.2) 中运行这些测试页面(6534.52.7, r102985)) 和 Mobile Safari（最新版本2011/12/28），只有 Mobile Safari 的性能与 FireFox 一样好。桌面浏览器在 MacBook Pro 上进行了测试。

2.7 GHz Intel Core i7
8 GB 1333 MHz DDR3

有趣的是，在渲染测试页面。尽管 Mobile Safari 基于 WebKit，但在本例中它的表现完全不同。

将 setTimeout 调用从 244 减少到 144 似乎也没有做任何事情。在这一点上，我完全任意地达到了244，因为很早就很清楚，与调用相比，显示的时间似乎几乎不直接对应。这让我相信我正在每个浏览器上尽可能快地渲染幻灯片。

所以我的问题是，如何在 WebKit 中实现此功能？

原文

I'm currently working on a little site for my family. One of the things I wanted to do was to make a basic 'making of' stop-motion video. I could assemble it and upload it to Vimeo or something but I thought it was a perfect opportunity to use nothing but HTML, CSS, and Javascript.

I've got everything styled and my JS is working, etc. except that it performs atrociously in Chrome and Safari. Interestingly, it works great in Firefox and I'm not supporting it yet in IE. I'm hoping for 8 to 12 frames per second, with music playing, which I haven't bothered trying yet due to this. Bad performance is anything less than that. Currently I'm getting roughly 3 fps in Firefox (acceptable, but not what I was looking for) and in Chrome and Safari I'm getting roughly .6795 fps.

When running the Chrome Profiler, I get the following (relevant) output.

99.96%   99.96%     (program)
0.03%    0.03%      (garbage collector)
0.01%    0.01%      script.js:5:nextSlide

I've never used the Profiler before but I believe this is showing me that my JS is not what's hitting the performance so hard.

I've published a test page that documents the performance differences that you can visit with Chrome and Firefox.

I've also discovered that this seems to be related to the images cycled. Cycling different, simpler images seems to work just fine in both Chrome and Firefox, despite the fact that Chrome is still a little more power hungry than Firefox.

As further proof of at least this conclusion, though it's entirely unacceptable, is demonstrated here, after running the images through convert -compress JPEG -quality 1. They cycle much more efficiently, but of course the quality is terrible.

I have run these test pages in Chrome (16.0.912.63), Safari (5.1.2 (6534.52.7)), WebKit nightly (Version 5.1.2 (6534.52.7, r102985)), and Mobile Safari (latest as of 2011/12/28) and only Mobile Safari performs as well as FireFox. The desktop browsers were tested on a MacBook Pro.

2.7 GHz Intel Core i7
8 GB 1333 MHz DDR3

Interestingly, Mobile Safari on an iPad 2 performs as well as FireFox when rendering the test page. Though Mobile Safari is based on WebKit, in this instance it performs entirely different.

Decreasing the setTimeout call to 144 from 244 also seems to not do anything. I've arrived at 244 entirely arbitrarily at this point as it became clear early on that the timing of the display compared to the call didn't seem to correspond nearly directly. This leads me to believe that I'm rendering the slide show as quickly as I can on each browser.

So my question is, how can I make this performant in WebKit?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

南风起 2024-12-28 13:29:42

您可以使用 Chrome 开发者工具下的“时间轴”选项卡调试 Chrome 中的页面性能。您的脚本的问题在于您的重绘周期太昂贵，目前每帧重绘需要 1.35 秒。

在此处输入图像描述

性能不佳与 jpeg 图像的质量无关（尽管图像质量也会影响页面渲染时间）。问题是您正在更新 z-index，这会导致 Chrome 重新绘制所有图像，而不仅仅是下一帧（您有一个 O(n) 图像滑块网站！）。

浏览器尝试执行尽可能少的操作来响应更改，例如：元素颜色的更改只会导致元素的重新绘制。

更改元素 z-index 属性基本上与从树中删除一个节点并向其添加另一个节点相同。这将导致元素、其子元素以及可能的同级元素的布局和重新绘制。我的猜测是，在 Chrome 中，兄弟姐妹也被重新绘制，这解释了糟糕的性能。

解决此问题的一种方法是更新 opacity 属性而不是 z-index。与 z-index 不同，opacity 不会修改 DOM 树。它只告诉渲染器忽略该元素。该元素仍然“物理”存在于 DOM 中。这意味着只有一个元素会被重新绘制，而不是所有的兄弟元素和子元素。

CSS 中的这个简单更改应该可以解决问题：

.making-of .slide#slide-top {
   opacity: 1;
   /* z-index: 5000; */
}


.making-of .slide {
   position: fixed;
   /* z-index: 4000; */
   opacity: 0;
   ....
}

这就是结果，重绘从 1.35 秒变为 1 毫秒：

enter image这里的描述

编辑：

这是一个使用不透明解决方案的jsfiddle，我还添加了CSS3过渡（只是为了好玩！）

http://jsfiddle.net/KN7Y5/3/

有关浏览器渲染工作原理的更多信息：

http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/

You can debug the page performance in Chrome using the Timeline tab under the Chrome developer tools. The problem with your script is that your repaint cycle is simply too expensive, it currently takes 1.35s to repaint every frame.

enter image description here

The bad performance has nothing to do with the quality of the jpeg images (although the image quality also affects the page render time). The problem is that you are updating the z-index which causes the Chrome to repaint all images instead of just the next frame (You have a O(n) image slider website!).

The browsers try to do the minimal possible actions in response to a change e.g.: changes to an elements color will cause only repaint of the element.

Changing the element z-index property is basically the same as removing a node from the tree and adding another node to it. This will cause layout and repaint of the element, its children and possibly siblings. My guess is that in Chrome, the siblings are being repainted too, this explains the horrible performance.

A way to fix this problem is to update the opacity property instead of the z-index. Unlike the z-index, the opacity does not modifies the DOM tree. It only tells the render to ignore that element. The element is still 'physically' present in the DOM. That means that only one element gets repainted and not all siblings and children.

This simple changes in your CSS should do the trick:

.making-of .slide#slide-top {
   opacity: 1;
   /* z-index: 5000; */
}


.making-of .slide {
   position: fixed;
   /* z-index: 4000; */
   opacity: 0;
   ....
}

And this is the result, the repaint went from 1.35s to 1ms:

enter image description here

EDIT:

Here is a jsfiddle using the opacity solution, I also added CSS3 transitions (just for fun!)

http://jsfiddle.net/KN7Y5/3/

More info on how the browser rendering works:

http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/

回复收藏 0 原文

探春 2024-12-28 13:29:42

我查看了您网站上的代码，发现有两件事限制了速度。

1) 在 JavaScript 中，超时时间约为 1/4 秒（244 毫秒）。这意味着您的最佳投射帧速率约为 4 FPS（每秒帧数）。只需减少延迟以匹配您实际想要的帧速率即可解决此问题。 我发现您最近的编辑解决了这一点，但我不想忽略它，因为它对于实现您想要的更高帧速率至关重要。

2) 您正在使用 z-index 来控制哪个图像可见。一般情况下，z-index 处理允许对具有不同大小和位置的对象进行排序，以便您可以控制哪个对象在两个或多个对象重叠的位置可见。在您的情况下，所有对象都完美重叠，并且 z-index 方法工作正常，除了一个主要问题：浏览器不会针对这种情况优化 z-index 处理，因此它们实际上处理每个图像上的每个图像框架。我通过创建演示的修改版本验证了这一点，该版本使用了两倍的图像 - FPS 降低了近 2 倍（换句话说，显示整个集合所需的时间是原来的 4 倍）。

我编写了一种替代方法，可以在 Chrome 和 Firefox 下实现更高的 FPS（60 或更高）。要点是我使用了 display 属性而不是操作 z-index:

.making-of .slide#other {
   display: none;
}

.making-of .slide#slide-top {
   display: inline;
}

和 JavaScript：

function nextSlide() {
  ...
  topSlide.id='other';
  nextTopSlide.id='slide-top';
  ...
  setTimeout(nextSlide, 1);
  ...
}

我也在 HTML 中做了一些更改，特别是包括 id="other" 在每个图像的标签中。

那么为什么 WebKit 这么慢？ 正如其他评论中所指出的，您在 Webkit 上看到的极差性能似乎是 Mac 特有的。我对此的最佳猜测是，Mac 版本的 WebKit 实际上并未使用 libjpeg 的“turbo”版本（尽管它列在制作人员名单中）。在您的测试中，如果 JPEG 解压缩实际上解压缩每一帧上的每个图像（很可能就是这种情况），那么 JPEG 解压缩很可能是选通因素。 libjpeg- 的基准测试Turbo 的减压速度提高了约 5 倍。这大致符合您在 Firefox 和 Chrome 之间看到的差异（3 FPS 与 0.6795 FPS）。

有关 libjpeg-turbo 的更多说明以及该假设如何解释其他一些结果，请参阅我的其他答案。

I took a look at the code on your site and found two things that are limiting the speed.

1) In the JavaScript, you have a timeout of approximately 1/4 second (244 milliseconds). This means that your best-cast frame-rate is about 4 FPS (frames-per-second). This can be fixed by simply reducing the delay to match the frame rate that you actually want. I see that your most recent edit addresses this point, but I didn't want to ignore it since it is ultimately critical to achieving the higher frame-rates that you want.

2) You are using z-index to control which image is visible. In the general case, z-index handling allows for objects that have different sizes and positions to be ordered so that you can control which object is visible at locations where two or more objects overlap. In your case, all of the objects overlap perfectly, and the z-index approach works fine except for one major problem: browsers don't optimize z-index processing for this case and therefore they are actually processing every image on every frame. I verified this by creating a modified version of your demo which used twice as many images -- the FPS was reduced by nearly a factor of 2 (in other words, it took 4 times as long to display the entire set).

I hacked together an alternative approach that achieved a much higher FPS (60 or more) under both Chrome and Firefox. The gist of it was that I used the display property instead of manipulating z-index:

.making-of .slide#other {
   display: none;
}

.making-of .slide#slide-top {
   display: inline;
}

and the JavaScript:

function nextSlide() {
  ...
  topSlide.id='other';
  nextTopSlide.id='slide-top';
  ...
  setTimeout(nextSlide, 1);
  ...
}

I made some changes in the HTML too, notably including id="other" in the tag for each image.

So why is WebKit so slow? As has been pointed out in other comments, the extra-poor performance that you are seeing on Webkit seems to be Mac specific. My best guess about this is that the Mac version of WebKit is not actually using the "turbo" version of libjpeg (despite the fact that it is listed in the credits). In your test, JPEG decompression could very well be the gating factor if it is actually decompressing every image on every frame (as is likely the case). Benchmarking of libjpeg-turbo has shown about a 5x improvement in decompression speed. This roughly matches the difference that you are seeing between Firefox and Chrome (3 FPS vs. 0.6795 FPS).

For more notes on libjpeg-turbo and how this hypothesis explains some of your other results, see my other answer.

回复收藏 0 原文