HTML5 Canvas在Chrome上速度较慢，但​​在FireFox上速度很快

Question

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.

Answer 1

Edit : Issue was not down to the issues raised in this answer. I've also edited the code to be a little more informative.

---

BlueMonkMN : 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.

Looking at your code (below), I can see that your event handler code is calling redraw methods ( this is why a lot of the cpu time is spent in event handlers ). All it should be doing is updating state. Your redraw should take place in your Game Loop , which would make it much easier to manage as a whole.

Consider removing the use of instanceof in MapLayer.prototype.draw and instead finding another way to get the frames. instanceof is a costly operation, and there is often a much more elegant approach that does not require that. Some of those Tile/Map objects should be accessed through function calls rather than array indexes, then you can have more freedom on the type of object returned, frames can be updates, and that whole MapLayer.prototype.draw method can be a lot cleaner.

Also, why is there a loop rendering every frame if typeof frames !== 'number' ? When debugging it tends to only be rendering two frames, but it stood out.

Again, you really ought to be rendering in the game loop, nothing major should ever take place in event handlers. And to make it easier, try constructing a benchmark for a single frame on jsperf.com , that way you will know how much time it spent in that function. And you can narrow down on the bottleneck by benchmarking different aspects of your code.

// Section of our code
function beginDrag(e) {
   dragX = e.clientX;
   dragY = e.clientY;
   var srcEl = e.srcElement ? e.srcElement : e.target;
   srcEl.onmousemove = processDrag;
   return false;
}
// **Note** called on mouseout, not mouseup
function endDrag(e) {
   var srcEl = e.srcElement ? e.srcElement : e.target;
   srcEl.onmousemove = null;
}
function processDrag(e) {
   e = e || window.event;
   drag(e.clientX, e.clientY);
   return false;
}
function drag(newX, newY) {
   currentMap.scroll(currentMap.scrollX + newX - dragX, currentMap.scrollY + newY - dragY);
   dragX = newX;
   dragY = newY;
   // --- this should not be executed during an event handler, draw takes place in game loop.
   currentMap.draw(gameViewContext);
}

Answer 2

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.