New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 464835 link

Starred by 61 users

Issue metadata

Status: Assigned
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Regression

issue 422000

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

context.drawImage() slows down massively when drawing a few large images in a batch

Reported by, Mar 6 2015

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.22 Safari/537.36

Steps to reproduce the problem:
IE11: Works
Firefox: Works
Chrome Dev/Nightly: Unusually slow image rendering at some threshold

1. Draw several large images onto an HTML Canvas with drawImage() in succession
2. This is very slow in Chrome
3. This is not slow in other browsers
4. Drawing the _same_ image the same number of times in succession is not slow
5. Drawing _one fewer_ image is back to being very fast. In other words there is some threshold.
6. See the example for a live demonstration

This problem does not seem based on image count per se, but on cumulative pixel size of the drawing batch. In my example going from 10 images to 11 images produces a massive slowdown in rendering speed, but if you used differently sized images the numbers would be different.

Here's a simple example:

The same code is also attached as a .html page.

The slowdown is VERY apparent. In my library while dragging an object with 11 images on the screen vs. 10, context.drawImage() went from taking up 0.17% of total time to 60% of total time.

Sorry my code looks like crap, I initially discovered this in a library and wrote this out while crying into a bucket of ice cream (the usual).

What is the expected behavior?
draws real fast like the other browsers

What went wrong?
draws real slow unlike the other browsers

Did this work before? N/A 

Chrome version: 42.0.2311.22  Channel: dev
OS Version: 6.3
Flash Version: Shockwave Flash 17.0 r0

I wish chrome let me skip the issue wizard like firefox does
2.6 KB View Download

Comment 1 by, Mar 10 2015

Labels: Cr-Blink-Canvas
Labels: -Pri-2 -Type-Bug -OS-Windows Pri-1 Type-Bug-Regression OS-All M-42
Status: Assigned
Good Build:

29.0.1525.0   Base Position:  203508

Bad Build:

29.0.1530.0   Base Position:  204370

Able to repro this issue on Windows 7, 8, 8.1, MAC (10.9.5) & Ubuntu (14.04) for the Google Chrome Stable Version - 41.0.2272.89 & Google Chrome Canary Version - 43.0.2329.0

This is a regression issue broken in M29, below mentioned is the bisect info:



Suspecting: 151815

@piman: Could you please check whether this is caused with respect to your change, if not could you please assign it to the right owner.

Thank you.

Comment 3 by, Mar 13 2015

Err. A change from a year and a half ago isn't responsible for a recent regression.

junov: I think you've been poking around canvas regressions, do you know if this sounds similar?

Comment 4 by, Mar 17 2015

This sound like we are hitting the limits of the Ganesh texture cache. bsalomon has made changes in this area not too long ago. 

IMHO plain LRU eviction is bad because it causes catastrophic performance degradations in cyclic access patterns when the cache threshold is exceeded: You go from 100% to 0% cache hits by adding a single element to the working set. Some kind of weighted randomized eviction would perform a lot better. Or perhaps a mix: LRU on dead resources and MRU on live resources. "live" = used in painting the current or previous frame.

Comment 5 by, Jul 16 2015

Labels: -Pri-1 -M-42 Pri-2 M-46
We have encountered this issue while implementing an HTML5 library.
Performance when rendering lots of images as dropped.

Now, any other browser is faster than chrome.

Is there any plan to fix this issue ?

Comment 7 Deleted

Comment 8 by Deleted ...@, Aug 9 2015

This issue has been happening to me in Chrome for over 6 months.

Because of how slow Chrome is at drawImage with large resolutions, I have been using Firefox which is about 700x faster in drawing 1920x1080 images to the canvas.

In Chrome,
When I draw a 1280x720 image I get 60 fps, but when I draw a 1440x900 I get 1 fps.

Comment 9 by, Aug 10 2015

This is being actively addressed by Joshua.

Comment 11 Deleted

Comment 12 by Deleted ...@, Aug 12 2015

Hey Joshua, this is the thing I am working on that uses Canvas. If you want me to give you some specific real-use examples where drawImage slows my stuff down, let me know.

I got it running at 60 fps at 1080p, but I want to push it farther once Chrome works as well as Firefox. Thank you for taking a look!
Thanks Marti.  This is probably going to take a couple of patches to fix correctly.
Project Member

Comment 15 by, Aug 17 2015

The following revision refers to this bug:

commit 29553b39bbfe55f2fad9028d5f4e823db7c99c22
Author: joshualitt <>
Date: Mon Aug 17 14:20:58 2015

Revert of drawBitmapImage can batch across AA rects (patchset #5 id:80001 of )

Reason for revert:
a follow up patch exposes a bug

Original issue's description:
> drawBitmapImage can batch across AA rects
> BUG=464835
> Committed:,,

Review URL:


Comment 16 by, Aug 17 2015

For the use case in comment #11: As far as I can tell cache evictions are not the issue there. I think that use case is mostly fixed by this change that landed last week :
Combined with this change that is about to land:

@marti.michael: Try out the Chrome Canary in a couple days, and let us know.
has this been fixed? I have been running in degraded performance issues with caused by drawImage
We are still working on this, it turns out a fix is going to take more time then we anticipated.
Labels: -Pri-2 Pri-3
I hate to do this because we are still working on this, but a fix is a long time coming and I'm not going to have time to make a concerted effort towards this for at least another quarter or two.
Well, then you might just as well set it as won't fix. Given this bug and people won't be using Canvas by that time anymore anyway - or will have moved to other, working browsers instead.
Seriously: can't you escalate this bug and have someone from google work on this instead - don't they have the man power to support their browser?

Comment 22 by Deleted ...@, Dec 20 2015

You know it's sad when Firefox, Safari for Mac desktop, and INTERNET EXPLORER have better performance than Chrome when rendering large images using drawImage.

A fix soon would be great considering your user base assumes it's the game engine's fault for running so slow, when in reality, they've just chosen a browser built by one of the best companies in the world that runs like it's built for a toaster.
I think the discussion investigation and discussion here got a bit off the rails.

For the example in the OP the issue is a massive slowdown when the cache is exceeded. As Justin points out our LRU policy fails catastrophically in this case. I'd like to experiment with other strategies to mitigate this. However, with the current budget we will always have to do at least 1 large upload per frame here and that will significantly slow it down. In parallel to improving the cache policy we should look at setting a larger budget for canvas 2D when possible. 96MB is paltry on a lot of systems. Justin, is that something you could take up? (comment #11) seems to encounter this same problem when the window gets *really* large because it uses a handful of images sized to the game's canvas. At a normal window size they fit in the cache but when I stretched the window across two large displays performance falls off a cliff. I suspect when Justin and Joshua were investigating this they probably didn't make the window large enough to encounter this. Thus Joshua's was investigating how to make the already fast case marginally faster.
I should note that in the past increasing the budget posed a problem in that depending on drawing patterns we may continuously grow the memory used (until we hit the budget) even when any given frame has a low memory requirement. However, Ganesh now preemptively removes resources that haven't been used in many flushes even when under budget.
I can look into adjusting the budget. I think raising it for desktop (vs. Android) would make sense. Before doing that I would like to set-up some usage metrics to track failed GPU resource allocations in drawImage to make sure we don't adversely affect rendering reliability.
Project Member

Comment 26 by, Jan 7 2016

The following revision refers to this bug:

commit 0cad1f4cc187083f997c91f117529ba3ff5b191a
Author: junov <>
Date: Thu Jan 07 21:48:51 2016

Add GL error usage metrics for glTexImage* APIs

This change adds histograms that track errors that occur in
calls that allocate GPU textures. The motivation is to track
the impact of tweaking GPU resource management parameters.
In particular, there is a desire to increase the limit of the
skia texture cache in order to solve some performance issues.
This histogram will allow us to measure the impact of that
change on GPU resource allocation failure rates.


Review URL:

Cr-Commit-Position: refs/heads/master@{#368165}


Before playing with cache sizes, I am going to wait for the new metrics to hit the beta channel so that we have reasonably reliable stats to validate the impact on rendering reliability.
 Issue 305617  has been merged into this issue.
Chrome + GPU + large images = DEATH

Interesting how an issue from 2013 is considered a dup of an issue from 2015 (see comment #22 in   issue 305617 ).

A workaround in Chrome is to disable the GPU, and then examples work great and run fast!

It is a crime that other web browsers work fine and fast (especially IE, which can handle huge images just fine), but Chrome+GPU=SLOW.

Please fix this issue once and for all, and hopefully sooner rather than later.

Since  issue 305617  is considered a 'duplicate' of this issue, any 'fix' for this issue also needs to fix  issue 305617  as well.  In summary,  issue 305617  showed a "1000-fold performance hit in canvas.drawImage() when the image is large"  And 'large' could be a *single* JPG from a Nikon 810 camera.

Having a hard coded 96MB limit ( ) in Chrome, when the GPU is used, must be addressed.  Simply raising the limit to another (higher) hard coded limit is NOT a solution either.

junov, what is the status of this issue?

Please test any solutions for this issue against this test: Go to, click on the gear icon, and check 'huge' under 'background image' (Chrome manipulating large images causes VSYNC problems).
Components: Internals>Skia
Sorry about the delay in addressing this. I will try bumping up the texture cache size, at least on desktop chrome, which is duct tape mitigation, but it should still be done.

@bsalomon: any progress on improving the cache eviction strategy?
I would like to suggest having a two-tiered cache limit approach to allow a much higher limit for live resources (anything that was used since the previous frame).
No we haven't looked at that yet. For GPU raster I believe there is now a two level cache budget decision. Devices with a larger amount of VRAM get a larger total budget. Perhaps something similar should be adopted for c2d? Or if we are headed towards using display list canvas in combo with GPU raster then we'd inherit GPU raster's decision.

For your latter suggestion, one way of implementing that is to just hold on to the refs of SkImages used in the last frame. It might not be the best way to land it but could be used for experimentation.
Thanks for not giving up on this, guys.
Blocking: 422000

> Sorry about the delay in addressing this. I will try bumping
> up the texture cache size, at least on desktop chrome, which
> is duct tape mitigation, but it should still be done.

Is this change still on the table to be addressed soon?

All other web browsers have MUCH higher GPU memory limit than Chrome.

It would be nice to see a limit that is based upon a formula: like the maximum of some (larger) hard coded value, and a percentage of VRAM?

If looking at other formulas, please disclose for discussion?
Re #33, #34: The cache eviction strategy does now change when Skia detects it is consistently over budget to avoid worst case behavior. It improves performance in large or many image scenarios from horrendous to merely really bad. To really address this either the budget must be increased or blink has to take over managing image texture lifetime (for example by converting sw images to texture-backed SkImages). For GPU raster cc has moved in this latter direction. It creates explicit texture images outside of Skia's budget and owns lifetime management.
I can't really provide any particular test for this. I just want to mention that we've been working on an HTML5 game ( since end of 2011 and we've seen a major slow down of canvas2D performance over the years. We're using and old Nodewebkit version with Chromium 30.0.1599.66 which has vastly superior rendering performance compared to a modern Chrome/Chromium browser for our game. 

The game can be tested here:

I suspect that this issue is likely the culprit for these performance problem, since profiling always leads to a slow performance of drawImage calls and our game tends to draw a lot of images for more complex scenes.

Consequently I'd really like to see this issue fixed. This is the major reason why we can't update to a newer version of NW.js (that would on the other hand fix issues we have with Web Audio).

Otherwise a question: is this issue limited to canvas2d? Or in other word: would switching to WebGL for rendering be a possible workaround to improve performance?

If it helps, we can provide critical scenes from the game where the performance is especially bad with modern chromium versions.

Comment 41 by, Dec 16 2016

WebGL would most likely help because you'd get to explicitly control the image resources that reside in GPU memory.

One thing you could try is to load your game's sprite sheets into an intermediate canvas element. This will guarantee that the image resources stay in RAM (or possibly in GPU memory), in decoded form.  If you are not careful though, this can lead to a huge increase in memory consumption, and eventually out-of-memory crashes of the browser, so yo have to be pro-active about discarding (or recycling) canvases that contain resources that you don't need any more (e.g. when changing levels in the game).  When discarding a canvas, set its size to zero before discarding so that the GPU memory used by the canvas can be release right away instead of waiting for garbage collection.

Thanks a lot for the suggestions. It is weird though, since most large scale images that we draw are already intermediate canvas elements (things like the prerendered map chunks and effects). I'll probably do some detailed test to pinpoint which images exactly take longest to draw.

Otherwise I'm seriously considering porting our code to WebGL. It's risky at this point though, we're pretty far in development already.

Comment 43 by, Dec 23 2016

Currently in the process of writing an easy to view example, but I've experienced a huge drawImage performance decrease between Chrome 54 and 55 on Mac OS X (Yosemite and Sierra) in an audio visualisation program I've written called modV. ( )

modV relies heavily on drawImage to combine the Canvas between many 2D and 3D (WebGL) contexts. Where I could easily combine maybe 20-25 1920x1080 Canvas elements in 54, I can barely manage 2 in 55. (I've downloaded both 54 and 55 and tested against the same version of my code for modV)

Again, example in progress, I'll post back when I have it.

Comment 44 Deleted

Comment 45 by, Jan 7 2017

Hi, I was able to find time to write a simple test to illustrate the 54/55 drawImage (I think it's drawImage at least) regression.

YouTube video:

In the YouTube video, watch the FPS vs the resolution.
Chrome 54 behaves as expected - lower drawImage performance as the Canvases become larger.

Chrome 55, however, behaves strangely. At a fairly low resolution it staggers at around 15fps, then becomes smoother again when the resolution is increased but over around 700px width in the video we drop to 15 or less FPS again, then anything above 800px width is totally smooth again.

Although this may look like bad implementation, this has been affected my own modV project (linked to in the previous comment) and also does not explain the performance difference between Chrome 54 and 55.

This was tested on macOS Sierra 10.12.2 and I have been able to recreate the bug on Windows 10.

Please let me know if this warrants a new issue.
Thanks for that example in #45.  We will definitely be able to take action based on that.
Project Member

Comment 47 by, Jan 11 2017

The following revision refers to this bug:

commit 31d1c20abfddf002c516cb7b20c83aa804273a33
Author: junov <>
Date: Wed Jan 11 22:31:08 2017

Adding 2d canvas benchmark for GPU to non-GPU drawImage calls.


Cr-Commit-Position: refs/heads/master@{#443021}


Project Member

Comment 48 by, Jan 16 2017

The following revision refers to this bug:

commit 41d279a5476937a3981a8413be722d42da0de0d2
Author: junov <>
Date: Mon Jan 16 18:13:50 2017

Add an heuristic for promoting canvases to GPU acceleration

This change adds a new condition under which 2D canvases should be
promoted to GPU acceleration: if a gpu-accelerated source is drawn to
it. There was a pre-existing heuristic for disabling acceleration on
the source if the source is a 2D canvas. Promoting the destination,
if possible, is usually preferable. This also has benefits when the
source is a WebGL canvas or a video.

BUG=464835,  524628 

Cr-Commit-Position: refs/heads/master@{#443923}


We have observed a seemingly related significant regression in canvas 2d drawImage performance. It appears to have hit somewhere between Chrome version 50 and version 55 in our app at Clipping Magic ( From what testing we've been able to do, it applies to Chrome on Windows 10 when drawing multiple large off-screen canvases to another on-screen canvas. The size threshold appears to depend on the hardware somewhat but is triggered around 4 or 5 off-screen canvases of at least 6 to 8 megapixels being drawn to one or two smaller on-screen canvases. None of the other browsers are having any problems, and Chrome on Mac does not appear to have an issue with our app. 

Notably, and unlike some of the other examples given in this thread, our app's drawing routines are not an animation. Rather, scene redraws are triggered by user events, usually mouse events. On the hardware available to us for testing, the other browsers are hitting about 60 fps while Chrome falls off a cliff above a certain megapixel size and drops to a couple frames per second, with gaps of irregular length between frames. 

The profiler indicates the lag is entirely due to the self-time of drawImage. In testing, we've additionally done our best to isolate the cause be removing unnecessary drawing operations from our code, and the problem remains. 

I'm happy to provide additional information to the Chromium team if it would be at all helpful. Please email me directly if I can be of assistance on this.

Comment 50 by, Jan 23 2017

Status: Fixed (was: Assigned)
I am closing this issue as Fixed because the test case in the bug description is resolved.
To all the people following this bug: For other uses cases that are still problematic as of the latest build, please file new bugs.

Get the latest official build from the Chrome Canary channel, here:

junov, not fixed. see issue 683976
Please do not mark this as resolved. I just my site in the canary browser and the bug very much still exists.
WOW, correct -- problem still exists running the test case ( under Canary.  This issue must be reopened!

Comment 54 by, Jan 23 2017

Going forward, lets track these bugs separately from this one since they don't all have the same root cause.

@#51: Thanks for filing a specific case for follow-up.
@#52: Please spin-off a new bug (click the "new issue" button on the top left corner of this page. And please provide a URL or attach sample code, with instruction on how to reproduce the problem.  Thanks.

Comment 55 by, Jan 23 2017

Status: Assigned (was: Fixed)

Comment 56 by, Jan 23 2017

@#53: Whoops, thanks for pointing this out. Clerical error on my part. The fix from comment 48 was not meant to be associated with this bug, it is a fix just for  issue 524628 
I don't believe this is a separate issue, and my subject line would be identical were I to open a new issue, so I'm going to include my reproducible test case here:

That link should open up our background-removal app with a test image of a purse on a table. It will have two view panes, the left showing the original image, along with some red and green highlighter markings, and the right pane showing the same but with the background removed and only the purse showing.

The default tool selection will be the hand tool, which allows you to click and drag on either view pane to pan the image in the view. To reproduce the bug, click and drag on the image and the panning operation will be very choppy and slow. I have reproduced this on three different computers, all running windows 10 and Chrome version 55.0.2883.87 m. The problem does not manifest on older versions on Chrome (I believe I tested version 50 or 51 and it worked fine) on Windows 10, nor does it manifest on the latest versions of Firefox or Edge for Windows. I have also tested the latest versions of Firefox, Safari, and Chrome on Mac and the problem does not appear.

The sample image provided in that link is 8 megapixels. There are two view pane canvas elements for on-screen display. On the left pane, there are three 8 megapixel canvas elements drawn to the on-screen canvas element. On the right pane, there is a single 8 megapixel canvas element drawn to the on-screen canvas element.

The problem does not appear for smaller test images, and in my development environment, I can get the problem to go away by commenting out the drawing of all the layers except the original image and the result image. That is, the problem manifests from drawing multiple large canvas elements to the same target canvas element.
ja/57: You may want to file a NEW issue regardless, same subject line as this issue, with the body from your comment and back link to this issue (just like I did in  issue 683976).  Hopefully a fix here will fix your new issue, but if not, you then have a bug report that was filed 'a long time ago'...
Ok, I've filed a new issue at:
I know a new issue is keeping track of this, and the case that I submitted seems fixed. Close this issue?

Comment 61 by, Sep 11 2017

I'd rather keep this open because there is ongoing long-term work that will affect this and other similar use cases. The team needs to come back and check on this issue later, once major GPU infrastructure changes have landed. I tried submitting this as a new issue but it would not post. The following is an outline of what seems to be the same issue:

Steps to reproduce the problem:
1. Draw here in our canvas which is 1376 x 1032 px: 
2. There is a major slow down 
3. Here is a video demonstration of the bug:
4. Draw here in a canvas that is 1024 x 768:
5. There is no slowdown
6. Here is a video demonstrating no bug at 1024 x 768:

What is the expected behavior?
On, we would like our users to be able to draw on a canvas that is much larger than 1024 x 1024 without having a massive slow down. In Firefox and Safari, there is no slowdown when drawing in the 1376 x 1032 canvas 

Here is a video of using our drawing app in a 1376 x 1032 canvas in Firefox:

What went wrong?
There is a major slow down when drawing in a canvas that is larger than 1024 x 1024.

Any other comments?
We have a userbase of illustrators who are in need of a larger canvas size which does not slow down. 
This issue has not been resolved for over 3 years. Here are other issues being tracked by the Chromium team which are identical to my issue:
Owner: ----
Status: Available (was: Assigned)
This bug has come back in a major way with version 69, which has terrible canvas draw performance when drawing large canvases. See also:
Labels: -Pri-3 Pri-2
Status: Assigned (was: Available)
Assigned to senorblanco while fserb is out.
Sorry, but last version 69 is very slow for demonstrated on canvas many
litle images, and version 70 develope is very good.

пн, 10 сент. 2018 г., 21:00 e… via monorail <>:
I haven't bisected yet, but possibly a dupe of ?
Thanks for the quick help! Version 69.0.3497.92 is great.

Sign in to add a comment