HTML5 Canvas 在 Chrome 上很慢，但在 FireFox 上很快
时间：2023-06-20问题描述
我正在双核 2.8 GHz Pentium Windows 7 系统上测试 Chrome 15.0.874.106m，配备 4 GB RAM(以及具有大量内存的高度加速的视频卡)，我正在测试 FireFox 7.0.1具有 2 GB RAM 的单核 1.6 GHz Athalon Windows Vista 笔记本电脑.然而，FireFox 系统的性能比 Chrome 系统高出大约 10 倍(我的视觉估计是 FPS 的 10 倍).
我看到的大多数帖子在 FireFox 和 Chrome 上的表现都不错，但在这里我似乎遇到了严重相反的情况.关于什么可能对此负责的任何想法?我正在测试的 HTML 文件(单个文件，无依赖关系)约为 33 MB(压缩后为 16 MB)并且可用 这里.
这是对 HTML5 画布性能的跟进小文件和大文件.
我发现了 chrome://tracing，它帮助我通过 chrome 分析器运行问题文件获得了这些分析结果:
结果已删除，我得到了一些新的更有趣的结果，我将在新部分中描述(见下文). 结束编辑强>
我还发现了 --show-fps-counter，它显示滚动运行在 3.5 FPS 左右.但是我仍然不清楚问题出在哪里.
我还找到了 --use-gl 开关并尝试了桌面、egl 和 osmesa.osmesa 的性能似乎是最好的，但只是勉强.我无法准确说出多少，因为 show-fps-counter 开关显然不能与 use-gl=osmesa 一起使用.osmesa 在其他系统上的性能仍然不如 FireFox.
编辑继续:多亏了事件处理中的侥幸，我以某种方式进入了一种无需按住鼠标按钮即可滚动地图的模式.令我震惊和惊讶的是，它滚动得非常流畅！通过一些额外的编辑(即删除处理 mouseup 事件的代码)，我切换了代码，这样我就不需要按住按钮来滚动了.瞧，只要我不按住鼠标按钮，我就可以始终流畅地滚动非常.因此，我使用 chrome://tracing 来分析/跟踪行为，无论是否按住鼠标按钮.我的结果如下.
这是无需按住鼠标按钮的平滑滚动:
<上一页>评选总结:RenderWidget::OnHandleInputEvent : 1340.968ms 212 次RenderWidget::InvalidationCallback : 7.867ms 27 次RenderWidget::OnUpdateRectAck : 1.319ms 173 次出现RenderWidget::OnSwapBuffersComplete : 129.018ms 173 次V8EventListener::callListenerFunction : 1306.923ms 173 次出现RenderWidget::DoDeferredUpdate : 120.033ms 204 次EarlyOut_UpdateReplyPending:0.004ms 4 次EarlyOut_SwapStillPending:0.181ms 165 次出现CommandBufferHelper::WaitForToken : 8.358ms 3 次WebViewImpl::layout : 1.24ms 190 次CCLayerTreeHost::updateLayers : 34.726ms 173 次CCLayerTreeHost::commitTo : 24.426ms 173 次CCLayerTreeHostImpl::drawLayers : 24.483ms 173 次LayerRendererChromium::present : 8.434ms 173 次出现EarlyOut_NoPendingUpdate:0.018ms 17 次CommandBufferProxy::FlushSync : 8.307ms 3 次CCLayerTreeHost::updateLayers::calcDrawEtc : 15.871ms 173 次LayerRendererChromium::drawLayers : 23.441ms 173 次RenderWidget::OnSwapBuffersPosted : 0.185ms 173 次出现RendererGLContext::SwapBuffers : 4.431ms 173 次LayerRendererChromium::drawLayersInternal::calcDrawEtc : 10.783ms 173 次GpuCommandBufferStub::OnFlush : 7.581ms 3 次GpuCommandBufferStub::OnAsyncFlush : 2825.339ms 352 次GpuCommandBufferStub::OnEcho : 0.83ms 173 次出现GpuScheduler:PutChanged : 2823.239ms 355 次GLES2DecoderImpl::HandleTexImage2D : 5.779ms 6 次GLES2DecoderImpl::HandleTexSubImage2D : 1.784ms 3 次出现GLES2DecoderImpl::HandleSwapBuffers : 2387.561ms 173 次GLContext::SwapBuffers : 2384.623ms 173 次ScheduledAction::execute : 2.453ms 16 次v8.compile : 1.037ms 14 次v8.run : 3.142ms 14 次EarlyOut_NotVisible:0.021ms 14 次出现RenderWidgetHost::ForwardMouseEvent : 7.465ms 538 次RenderWidgetHost::OnMsgInputEventAck : 5.218ms 212 次RenderWidgetHost::OnMsgUpdateRect : 4.172ms 173 次RenderWidgetHost::ForwardInputEvent : 4.551ms 212 次*总计:13535.811ms 5332 次出现选择开始:986.276ms选择范围:3320.488ms这是按住鼠标按钮时的断断续续/缓慢滚动:
<上一页>评选总结:RenderWidget::OnHandleInputEvent : 3852.921ms 61 次RenderWidget::InvalidationCallback : 4.549ms 61 次RenderWidget::OnUpdateRectAck : 1.235ms 40 次RenderWidget::OnSwapBuffersComplete : 20.684ms 40 次V8EventListener::callListenerFunction : 357.075ms 39 次RenderWidget::DoDeferredUpdate : 25.208ms 132 次EarlyOut_SwapStillPending:0.004ms 6 次EarlyOut_UpdateReplyPending:0.032ms 32 次出现CommandBufferHelper::WaitForToken : 8.09ms 3 次WebViewImpl::layout : 0.346ms 78 次CCLayerTreeHost::updateLayers : 7.805ms 40 次CCLayerTreeHost::commitTo : 4.727ms 40 次CCLayerTreeHostImpl::drawLayers : 9.449ms 40 次LayerRendererChromium::present : 1.122ms 40 次EarlyOut_NoPendingUpdate:0.038ms 38 次CommandBufferProxy::FlushSync : 8.05ms 3 次CCLayerTreeHost::updateLayers::calcDrawEtc : 3.694ms 40 次LayerRendererChromium::drawLayers : 9.177ms 40 次RenderWidget::OnSwapBuffersPosted : 0.035ms 40 次RendererGLContext::SwapBuffers : 0.684ms 40 次LayerTextureUpdaterCanvas::paint : 0.483ms 1 次出现LayerTextureSubImage::uploadWithMapTexSubImage : 0.02ms 1 次出现LayerRendererChromium::drawLayersInternal::calcDrawEtc : 2.329ms 40 次GpuCommandBufferStub::OnFlush : 7.326ms 3 次GpuCommandBufferStub::OnAsyncFlush : 226.88ms 121 次GpuCommandBufferStub::OnEcho : 0.377ms 40 次GpuScheduler:PutChanged : 230.2ms 124 次GLES2DecoderImpl::HandleTexImage2D : 5.705ms 8 次GLES2DecoderImpl::HandleTexSubImage2D : 2.057ms 4 次GLES2DecoderImpl::HandleSwapBuffers : 113.857ms 40 次GLContext::SwapBuffers : 113.377ms 40 次ScheduledAction::execute : 12.708ms 83 次v8.compile : 1.982ms 25 次v8.run : 4.499ms 25 次EarlyOut_NotVisible:0.022ms 25 次RenderWidgetHost::ForwardMouseEvent : 4.671ms 640 次RenderWidgetHost::OnMsgInputEventAck : 1.102ms 61 次RenderWidgetHost::OnMsgUpdateRect : 0.894ms 40 次RenderWidgetHost::ForwardInputEvent : 1.527ms 61 次*总计:5044.941ms 2235 次选择开始时间:956.043ms选择范围:6082.888ms从这个比较中，我觉得 Chrome 的 OnHandleInputEvent 实现在这里一直在吃光.怎么回事?
效果是可见的，只是在更小/更简单的项目上也没有那么明显.这是一个只有大约 700K 的示例，它比测试更易于管理30+ MB 的项目.如果您单击并拖动，您会看到滚动有点断断续续，但如果您松开鼠标按钮，它将继续滚动更加顺畅.
我报告的错误 (https://code.google.com/p/chromium/issues/detail?id=103148) 已被评论为无法复制"，如果我阅读正确，所以我'm 将假设这是 Chrome 中的一个错误并且已被其他更新修复(有意或无意).无论如何，我自己不再有这个问题了.
I'm testing Chrome 15.0.874.106m on a dual-core 2.8 GHz Pentium Windows 7 system with 4 GB RAM (and a highly accelerated video card with lots of memory) and I'm testing FireFox 7.0.1 on a single-core 1.6 GHz Athalon Windows Vista Laptop with 2 GB RAM. Yet the FireFox system is outperforming the Chrome system by about 10 times (10 times the FPS by my visual estimation).
Most of the posts I see are experiencing slower performance on FireFox and Chrome doing alright, but here I seem to have a severely reversed case. Any ideas on what could be responsible for this? The HTML file (single file, no dependencies) I'm testing is about 33 MB (16 MB compressed) and is available here.
This is a follow up to HTML5 canvas performance on small vs. large files.
I have discovered chrome://tracing which helped me acquire these profile results from running the problem file through the chrome profiler:
Edit: Results deleted, I got some new much more interesting results which I will describe in the new section (see below). End Edit
I also discovered the --show-fps-counter, which showed the scrolling running around 3.5 FPS. But I'm still not clear where the problem is.
I also found the --use-gl switch and tried desktop, egl and osmesa. The performance seemed to be best with osmesa, but only barely. I couldn't tell exactly how much because the show-fps-counter switch apparently doesn't work in conjunction with use-gl=osmesa. osmesa still doesn't perform nearly as well as FireFox on the other system.
Edit Continued: Thanks to a fluke in the event handling I somehow got into a mode where I could scroll the map without holding the mouse button down. To my shock and amazement, it was scrolling very smoothly! With a few additional edits (namely, removing the code that handles the mouseup event) I switched the code so that I never need to hold the button to scroll. Lo and behold, I can consistently scroll very smoothly so long as I am not holding down the mouse button. So I profiled/traced the behavior using chrome://tracing with and without holding the mouse button down. My results are below.
This is smooth scrolling without holding down the mouse button:
Selection summary: RenderWidget::OnHandleInputEvent : 1340.968ms 212 occurrences RenderWidget::InvalidationCallback : 7.867ms 27 occurrences RenderWidget::OnUpdateRectAck : 1.319ms 173 occurrences RenderWidget::OnSwapBuffersComplete : 129.018ms 173 occurrences V8EventListener::callListenerFunction : 1306.923ms 173 occurrences RenderWidget::DoDeferredUpdate : 120.033ms 204 occurrences EarlyOut_UpdateReplyPending : 0.004ms 4 occurrences EarlyOut_SwapStillPending : 0.181ms 165 occurrences CommandBufferHelper::WaitForToken : 8.358ms 3 occurrences WebViewImpl::layout : 1.24ms 190 occurrences CCLayerTreeHost::updateLayers : 34.726ms 173 occurrences CCLayerTreeHost::commitTo : 24.426ms 173 occurrences CCLayerTreeHostImpl::drawLayers : 24.483ms 173 occurrences LayerRendererChromium::present : 8.434ms 173 occurrences EarlyOut_NoPendingUpdate : 0.018ms 17 occurrences CommandBufferProxy::FlushSync : 8.307ms 3 occurrences CCLayerTreeHost::updateLayers::calcDrawEtc : 15.871ms 173 occurrences LayerRendererChromium::drawLayers : 23.441ms 173 occurrences RenderWidget::OnSwapBuffersPosted : 0.185ms 173 occurrences RendererGLContext::SwapBuffers : 4.431ms 173 occurrences LayerRendererChromium::drawLayersInternal::calcDrawEtc : 10.783ms 173 occurrences GpuCommandBufferStub::OnFlush : 7.581ms 3 occurrences GpuCommandBufferStub::OnAsyncFlush : 2825.339ms 352 occurrences GpuCommandBufferStub::OnEcho : 0.83ms 173 occurrences GpuScheduler:PutChanged : 2823.239ms 355 occurrences GLES2DecoderImpl::HandleTexImage2D : 5.779ms 6 occurrences GLES2DecoderImpl::HandleTexSubImage2D : 1.784ms 3 occurrences GLES2DecoderImpl::HandleSwapBuffers : 2387.561ms 173 occurrences GLContext::SwapBuffers : 2384.623ms 173 occurrences ScheduledAction::execute : 2.453ms 16 occurrences v8.compile : 1.037ms 14 occurrences v8.run : 3.142ms 14 occurrences EarlyOut_NotVisible : 0.021ms 14 occurrences RenderWidgetHost::ForwardMouseEvent : 7.465ms 538 occurrences RenderWidgetHost::OnMsgInputEventAck : 5.218ms 212 occurrences RenderWidgetHost::OnMsgUpdateRect : 4.172ms 173 occurrences RenderWidgetHost::ForwardInputEvent : 4.551ms 212 occurrences *Totals : 13535.811ms 5332 occurrences Selection start : 986.276ms Selection extent : 3320.488ms
And this is the choppy/slow scrolling when holding down the mouse button:
Selection summary: RenderWidget::OnHandleInputEvent : 3852.921ms 61 occurrences RenderWidget::InvalidationCallback : 4.549ms 61 occurrences RenderWidget::OnUpdateRectAck : 1.235ms 40 occurrences RenderWidget::OnSwapBuffersComplete : 20.684ms 40 occurrences V8EventListener::callListenerFunction : 357.075ms 39 occurrences RenderWidget::DoDeferredUpdate : 25.208ms 132 occurrences EarlyOut_SwapStillPending : 0.004ms 6 occurrences EarlyOut_UpdateReplyPending : 0.032ms 32 occurrences CommandBufferHelper::WaitForToken : 8.09ms 3 occurrences WebViewImpl::layout : 0.346ms 78 occurrences CCLayerTreeHost::updateLayers : 7.805ms 40 occurrences CCLayerTreeHost::commitTo : 4.727ms 40 occurrences CCLayerTreeHostImpl::drawLayers : 9.449ms 40 occurrences LayerRendererChromium::present : 1.122ms 40 occurrences EarlyOut_NoPendingUpdate : 0.038ms 38 occurrences CommandBufferProxy::FlushSync : 8.05ms 3 occurrences CCLayerTreeHost::updateLayers::calcDrawEtc : 3.694ms 40 occurrences LayerRendererChromium::drawLayers : 9.177ms 40 occurrences RenderWidget::OnSwapBuffersPosted : 0.035ms 40 occurrences RendererGLContext::SwapBuffers : 0.684ms 40 occurrences LayerTextureUpdaterCanvas::paint : 0.483ms 1 occurrences LayerTextureSubImage::uploadWithMapTexSubImage : 0.02ms 1 occurrences LayerRendererChromium::drawLayersInternal::calcDrawEtc : 2.329ms 40 occurrences GpuCommandBufferStub::OnFlush : 7.326ms 3 occurrences GpuCommandBufferStub::OnAsyncFlush : 226.88ms 121 occurrences GpuCommandBufferStub::OnEcho : 0.377ms 40 occurrences GpuScheduler:PutChanged : 230.2ms 124 occurrences GLES2DecoderImpl::HandleTexImage2D : 5.705ms 8 occurrences GLES2DecoderImpl::HandleTexSubImage2D : 2.057ms 4 occurrences GLES2DecoderImpl::HandleSwapBuffers : 113.857ms 40 occurrences GLContext::SwapBuffers : 113.377ms 40 occurrences ScheduledAction::execute : 12.708ms 83 occurrences v8.compile : 1.982ms 25 occurrences v8.run : 4.499ms 25 occurrences EarlyOut_NotVisible : 0.022ms 25 occurrences RenderWidgetHost::ForwardMouseEvent : 4.671ms 640 occurrences RenderWidgetHost::OnMsgInputEventAck : 1.102ms 61 occurrences RenderWidgetHost::OnMsgUpdateRect : 0.894ms 40 occurrences RenderWidgetHost::ForwardInputEvent : 1.527ms 61 occurrences *Totals : 5044.941ms 2235 occurrences Selection start : 956.043ms Selection extent : 6082.888ms
From this comparison, it looks to me like Chrome's OnHandleInputEvent implementation is eating up all the time here. What's going on?
The effect is visible, just not as pronounced even on much smaller/simpler projects. Here's an example that's only about 700K which is a much more manageable thing to test with than the 30+ MB project. If you click and drag you can see is scrolls slightly choppily, but if you release the mouse button it will continue scrolling much more smoothly.
The bug I reported (https://code.google.com/p/chromium/issues/detail?id=103148) has since been remarked on as "unable to reproduce" if I read correctly, so I'm going to run on the assumption that this was a bug in Chrome and has been fixed (intentionally or not) by other updates. In any case, I don't have the issue any more myself.
这篇关于HTML5 Canvas 在 Chrome 上很慢，但在 FireFox 上很快的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！
layer.open打开的页面关闭时，父页面刷新的方法layer.open打开的页面关闭时，父页面刷新的方法，在layer.open中添加： end: function(){ window.parent.location.reload();//关闭open打开的页面时，刷新父页面 }