OKOK. I have updated the sample code at  https://blight.ironhelmet.com/hardware

In this code I render 63 1024 jpegs into a canvas! 

Firefox, Edge on Windows handle it without breaking a sweat 17ms. 
Safari on Mac and iOS also a breeze. 17ms


Chrome on Windows is destroyed! - 300ms a frame or more. 
Chrome on Android Nexus 5 - 120ms
Chrome on Mac, a little better - 80 ms 

----

You can feel the slowness in real world situations which is why I started investigating in the first place. 

I have a game where the map is baked into a grid of 1024 textures. My work around has been to render the large textures into smaller canvases after they are downloaded (512 and 256) and as the player zooms the map in, selecting the textures closest to the output render size. 

Its not very nice, and given other browsers have some kind of optimisation baked in, it would be nice if Chrome had this as well. 

Have you tried with Chrome 55.0.2881.5 or later? There are recent changes that are worth evaluating.

Get the latest pre-release build here: https://www.google.com/chrome/browser/canary.html 

trace is attached (from Mac)

Deleted: trace_bad.json.gz 7.9 MB

trace_bad.json.gz 7.9 MB Download

Trace shows that this use case is thrashing the texture cache.  A large number of tiles are being re-uploaded to the GPU for each frame. I think we should revise some of our heuristic thresholds.  I'll look into this.

Thank you Xida for the preliminary investigation.

Hey Junov, do you think it's likely that we'll be able to get Chrome to perform like other browsers here?  

I would like to hold off on the release of my game if there is a fix coming down the pipe. 

If you tell me that this probably won't be fixed I would just go ahead and release now. 

I would be sad though. Chrome is my favorite browser! 

Hey there, Any thoughts or progress on this issue?

Hi, sorry about the delayed response. 

We should be able to fix this soon-ish, but it typically takes two or three months for fixes to reach a stable release, and several more weeks until most users have upgraded and restarted their browsers.

I am guessing you may not want to wait that long for your launch, so let's help you find a workaround.

After you call getContext('2d') on the game's main canvas, try calling .getImageData(0, 0, 1, 1) on the 2D context.  Call getImageData again every time the canvas is resized.

Here is the rationale behind the workaround:
The call to getImageData will trigger a performance heuristic that disables GPU acceleration. In general, we want GPU acceleration to be enabled, but your game hits an edge case that Chrome does not handle well. Until we fix Chrome to do a better job, you will get much better performance by disabling GPU-acceleration.

By the way, this solution is a total hack and you should probably only do it on browsers with a 'Chrome' or 'Chromium' user agent string. And remove the hack once this bug is fixed in stable releases of Chrome so that your game can go back to using the GPU.

I hope that helps. 

Ah, thanks very much Junov, great to hear that you expect to be able to fix it. 

I couldn't get the getImageData work around to work in my game, but I had mostly fixed it by saving smaller versions of the map textures into temporary canvases. Half and quarter sizes based on how much of the map could be seen. 

It's good to know that in 6 months or so I could remove this work around.

We are also most concerned with our performance in Electron so we don't need to wait for the changes to filter down to everybody, just to the Electron team. 

No progress on this yet Junov?

Not yet. This issue will be updated as soon as there is activity on this front.