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

Issue 305617 link

Starred by 17 users

Issue metadata

Status: Duplicate
Merged: issue 464835
Owner:
Last visit > 30 days ago
Closed: Jan 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

1000-fold performance hit in canvas.drawImage() when the image is large

Reported by jer...@duckware.com, Oct 9 2013

Issue description

Chrome Version       : 30.0.1599.69 (Official Build 226629) m
URLs (if applicable) : http://www.duckware.com/test/chrome/hugebug.html
Other browsers tested:
     Safari 5.1.7: OK
  Firefox 24: FAIL (test does not even run)
       IE 10: OK

What steps will reproduce the problem?
1. Visit URL and move mouse over the canvas/image
2. mouse wheel up/down.  Canvas performance should be excellent...
3. ...until left side of image passes left side of canvas, and performance takes a 1000-fold performance hit (same for right side of image and right side of canvas)

What is the expected result?

canvas.drawImage(...) should be very fast (<1ms)

What happens instead?

canvas.drawImage(...) takes over 1000ms

Please provide any additional information below. Attach a screenshot if
possible.
 
bad.jpg
113 KB View Download

Comment 1 by tkent@chromium.org, Oct 10 2013

Labels: Cr-Blink-Canvas Cr-Blink-Performance
Cc: srsridhar@chromium.org
Labels: Needs-Feedback
Tested the issue on Windows 7/8 and Mac 10.8.5 OS - in the reported chrome version and on latest canary.

Observed that scrolling up/down on the canvas, observed that performance takes 0 to 1 ms. 

Upon refreshing the page after scroll, it shows about 300 ms.

Please confirm if this is the issue you are mentioning about.

Comment 3 by jer...@duckware.com, Oct 10 2013

Sorry, let me try to clarify the test that is needed and what I am seeing:

1. Launch Chrome to the URL provided.
2. observed ms time is >1000ms, but expected as a first time init of the image
3. move mouse over the image and mouse wheel down, image moves left.  ms times are very fast (<1ms) and OK/expected.
4. KEEP mouse wheeling down and when the image edge starts to move outside the left edge of the canvas (in other words, when X in drawImage(image,X,...) goes negative by some amount), all of a sudden, drawImage() ms times skyrocket to over 1000ms for me.
5. I changed the test to display the X in drawImage().  What I see as I mouse down:

X=100 painted in 2074 ms (step 2)
X=90 painted in 0 ms (step 3)
X=80 painted in 0 ms (step 3)
X=70 painted in 1 ms (step 3)
X=60 painted in 0 ms (step 3)
X=50 painted in 0 ms (step 3)
X=40 painted in 1 ms (step 3)
X=30 painted in 0 ms (step 3)
X=20 painted in 1 ms (step 3)
X=10 painted in 0 ms (step 3)
X=0 painted in 0 ms (step 3)
X=-10 painted in 0 ms (step 3)
X=-20 painted in 0 ms (step 3)
X=-30 painted in 0 ms (step 3)
X=-40 painted in 1106 ms (step 4)
X=-50 painted in 1112 ms (step 4)
X=-60 painted in 1171 ms (step 4)
X=-70 painted in 1175 ms (step 4)

In Safari and IE, there is no step 4 as paint times are always <1ms.

Cc: junov@chromium.org
Thank you for the report. Could you post the contents of chrome://gpu to this bug?

On 30.0.1599.69 (Official Build 226629) on Mac, I'm seeing ~100ms draw times, regardless of position.

Tracing shows ~35ms in one large CommandBufferProxyImpl::FlushSync(), then a number of smaller Flush() and FlushSync() calls. All of this is from a single NativeImageSkia::draw(). But no 1000ms draws.

Comment 5 by jer...@duckware.com, Oct 10 2013

Graphics Feature Status
Canvas: Hardware accelerated
Compositing: Hardware accelerated on all pages and threaded
3D CSS: Hardware accelerated
CSS Animation: Accelerated and threaded
WebGL: Hardware accelerated
WebGL multisampling: Hardware accelerated
Flash 3D: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Texture Sharing: Hardware accelerated
Video Decode: Hardware accelerated
Video: Hardware accelerated
Driver Bug Workarounds
clear_alpha_in_readpixels
exit_on_context_lost
set_texture_filter_before_generating_mipmap
disable_d3d11
disable_angle_instanced_arrays
Version Information
Data exported	10/10/2013 9:03:58 AM
Chrome version	Chrome/30.0.1599.69
Operating system	Windows NT 6.1 SP1
Software rendering list version	6.5
Driver bug list version	2.6
ANGLE revision	2431
2D graphics backend	Skia
Performance Information
Graphics	5.9
Gaming	6.9
Overall	5.9
Driver Information
Initialization time	61
Sandboxed	false
GPU0	VENDOR = 0x8086, DEVICE= 0x0116
Optimus	true
AMD switchable	false
Driver vendor	Intel Corporation
Driver version	8.15.10.2321
Driver date	3-6-2011
Pixel shader version	3.0
Vertex shader version	3.0
Machine model	
GL version	2.0
GL_VENDOR	Google Inc.
GL_RENDERER	ANGLE (Intel(R) HD Graphics Family Direct3D9Ex vs_3_0 ps_3_0)
GL_VERSION	OpenGL ES 2.0 (ANGLE 1.2.0.2431)
GL_EXTENSIONS	GL_OES_element_index_uint GL_OES_packed_depth_stencil GL_OES_get_program_binary GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_npot GL_EXT_occlusion_query_boolean GL_EXT_read_format_bgra GL_EXT_robustness GL_EXT_texture_compression_dxt1 GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA8888 GL_EXT_texture_storage GL_EXT_frag_depth GL_ANGLE_depth_texture GL_ANGLE_framebuffer_blit GL_ANGLE_framebuffer_multisample GL_ANGLE_instanced_arrays GL_ANGLE_pack_reverse_row_order GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ANGLE_texture_usage GL_ANGLE_translated_shader_source GL_NV_fence
Window system binding vendor	Google Inc. (adapter LUID: 000000000000a755)
Window system binding version	1.4 (ANGLE 1.2.0.2431)
Window system binding extensions	EGL_EXT_create_context_robustness EGL_ANGLE_d3d_share_handle_client_buffer EGL_ANGLE_query_surface_pointer EGL_ANGLE_surface_d3d_texture_2d_share_handle EGL_NV_post_sub_buffer
Reset notification strategy	0x8252
Diagnostics
0
b3DAccelerationEnabled	true
b3DAccelerationExists	true
bAGPEnabled	true
bAGPExistenceValid	true
bAGPExists	true
bCanRenderWindow	true
bDDAccelerationEnabled	true
bDriverBeta	false
bDriverDebug	false
bDriverSigned	false
bDriverSignedValid	false
bNoHardware	false
dwBpp	32
dwDDIVersion	10
dwHeight	1080
dwRefreshRate	60
dwWHQLLevel	0
dwWidth	1920
iAdapter	0
lDriverSize	7472128
lMiniVddSize	0
szAGPStatusEnglish	Enabled
szAGPStatusLocalized	Enabled
szChipType	Intel(R) HD Graphics Family
szD3DStatusEnglish	Enabled
szD3DStatusLocalized	Enabled
szDACType	Internal
szDDIVersionEnglish	10.1
szDDIVersionLocalized	10.1
szDDStatusEnglish	Enabled
szDDStatusLocalized	Enabled
szDXVAHDEnglish	Supported
szDXVAModes	ModeMPEG2_A ModeMPEG2_C ModeWMV9_C ModeVC1_C
szDescription	Intel(R) HD Graphics Family
szDeviceId	0x0116
szDeviceIdentifier	{D7B78E66-4256-11CF-3669-B424B7C2C535}
szDeviceName	\\.\DISPLAY1
szDisplayMemoryEnglish	1696 MB
szDisplayMemoryLocalized	1696 MB
szDisplayModeEnglish	1920 x 1080 (32 bit) (60Hz)
szDisplayModeLocalized	1920 x 1080 (32 bit) (60Hz)
szDriverAssemblyVersion	8.15.10.2321
szDriverAttributes	Final Retail
szDriverDateEnglish	3/7/2011 16:52:22
szDriverDateLocalized	3/7/2011 4:52:22 PM
szDriverLanguageEnglish	English
szDriverLanguageLocalized	English
szDriverModelEnglish	WDDM 1.1
szDriverModelLocalized	WDDM 1.1
szDriverName	igdumd64.dll,igd10umd64.dll,igd10umd64.dll,igdumdx32,igd10umd32,igd10umd32
szDriverNodeStrongName	oem81.inf:Intel.Mfg.NTamd64:iSNBM0:8.15.10.2321:pci\ven_8086&dev_0116&subsys_04b81028
szDriverSignDate	
szDriverVersion	8.15.0010.2321
szKeyDeviceID	Enum\PCI\VEN_8086&DEV_0116&SUBSYS_04B81028&REV_09
szKeyDeviceKey	\Registry\Machine\System\CurrentControlSet\Control\Video\{02302C6C-8910-4107-9541-D9162CD113CF}\0000
szManufacturer	Intel Corporation
szMiniVdd	n/a
szMiniVddDateEnglish	n/a
szMiniVddDateLocalized	n/a
szMonitorMaxRes	
szMonitorName	Generic PnP Monitor
szNotesEnglish	No problems found.
szNotesLocalized	No problems found.
szOverlayEnglish	Supported
szRankOfInstalledDriver	00E60001
szRegHelpText	
szRevision	
szRevisionId	0x0009
szSubSysId	0x04B81028
szTestResultD3D7English	Not run
szTestResultD3D7Localized	Not run
szTestResultD3D8English	Not run
szTestResultD3D8Localized	Not run
szTestResultD3D9English	Not run
szTestResultD3D9Localized	Not run
szTestResultDDEnglish	Not run
szTestResultDDLocalized	Not run
szVdd	n/a
szVendorId	0x8086
Log Messages
GpuProcessHostUIShim: The GPU process exited normally. Everything is okay.

Comment 6 by jer...@duckware.com, Oct 10 2013

OK, I have a much better understanding of the problem.

The original image is 16291x2957.

I changed the test and added zoom levels.  The best way to test is with the lowest zoom level, so that the entire image is drawn to the canvas.

In the test URL above, but with a 10000x1815 image, Chrome does OK.  But as the image size increases, Chrome gets progressively worse -- until you reach the original 16291x2957 image, at a zoom of 0.05, now takes over 3300 ms to drawImage() -- see attached.

For comparison, when I ran the same test on an old 9-year old computer with no GPU, the drawImage to the canvas in Chrome took 30ms to complete!

Did someone hard-code a 100 MB limit?
chromeissue.jpg
99 KB View Download

Comment 7 Deleted

Comment 8 by jer...@duckware.com, Oct 10 2013

GPU issue confirmed!!  (hitting a 100MB GPU resource limit?)

When I run Chrome with --disable-gpu, ms times are less than 15ms (don't know exactly because it looks like performance.now resolution changes to 15ms accuracy).

Comment 9 by jer...@duckware.com, Oct 15 2013

Since Chrome's interface to the GPU has a bug in it somewhere, I hope you guys can fix this issue.  A frame rate of .3/second makes Chrome unusable, when IE takes less than 1ms on the same photo.
senorblanco@, Could you please update on this?

Thank you.
Cc: bsalomon@chromium.org
Labels: Cr-Internals-GPU-Canvas2D
Not sure (and I still can't repro this locally).  My guess is that the enormous source image is being uploaded repeatedly to the GPU, trashing Ganesh's cache, but I need to dig in a bit more.

In the meantime, if there's a way you can break up that large image into smaller chunks on your side, that would probably be improve things.
> break up that large image into smaller chunks
> on your side, that would probably be improve things.

No, SAME problem.  When the combined images start to total around 100MB (assuming four bytes per pixel), that is when problems really start to happen and ms times skyrocket.

Also, I just checked my web server log files.  It appears most of you are not running the test properly ... Don't just go to the web page and do nothing.  You actually have to click on the large/huge image links, to actually get the large/huge images to load, cross the 100MB threshold, and be used in the test, OK?  Also, for what it is worth, this is Chrome on *Windows*.  Running the test under Mac or Unix (as I see in the log files) and then saying you can't replicate the problem, is not helpful.

The reason for the initial small image size in the test is so that you call can see how fast it could/should be (should be less than 1ms).  With a GPU, image size should matter very little in ms times -- once the GPU has the image, telling it to drawImage() should always result in super fast ms times.

In fact, with --disable-accelerated-2d-canvas, my ms times for the huge image are 5 ms.  Yes, 5 ms.  So turn on the GPU in Chrome and that ms time then jumps to 3300ms.

Clearly Chrome has a serious GPU algorithm problem that should be looked into?


We can consider increasing the texture cache budget. But I'm wondering whether there might be a better way to render a 16291x2957 image at a zoom of .05 is a good idea. It seems like it'd be better for Skia could internally cache lower res versions of the image or for the site to generate a lower res version by rendering it to a smaller offscreen canvas and then using that as the src.
> But I'm wondering whether there might be a better way to render
> a 16291x2957 image at a zoom of .05 is a good idea.

It is NOT a good idea.  And you have completely missed the entire point of the test.  The test demonstrates the problem.  End of story.  The test in and of itself is meaningless, other than to trigger the problem.

So go back and read ALL prior messages.  But since the test has changed a little, let me repeat...

1) click on the huge image.
2) click on the zoom of 50% (0.5)
3) mouse wheel to move the image left
4) repeat and ms are really fast (<1ms for me)
5) but then at some point, ms times skyrocket (see attached).

Are you suggesting the Chrome is not capable of looking at a tiny window from a large image when using the GPU (>1000ms), and when the GPU is turned off, times drop to 5-6ms -- and that is OK?

If so, tell me and I will stop expending energy pointing out the Chrome bug.

If not, start expending energy to find the bug.
bsalo-needs-help.jpg
247 KB View Download
Cc: -bsalomon@chromium.org
OK, bsalo, Chrome has the bug with *NO* zoom.  See attached.

Draw a large image to a canvas with an X of 0 and ms times < 1ms

Draw a large image to a canvas with an X of -3350 and ms times jump to 1565 ms.


bsalo-needs-help-2.jpg
237 KB View Download
OK, because bsalo can't get past zoom, let's eliminate zoom from the test.  Here is a new TEST:

------------------------------------------------------------
<html><body>
<a href="javascript:draw(0)">draw1</a>
 | <a href="javascript:draw(-4000)">draw2</a>
 | <a href="javascript:draw(-5000)">draw3</a><br>
<canvas id="can" width=800 height=600></canvas>
<script>
var m_image = new Image();
m_image.src = "http://www.duckware.com/test/chrome/huge.jpg";
function draw(X) {
  var ctx = document.getElementById("can").getContext("2d");
  console.time("drawImage "+X);
  ctx.drawImage( m_image, X, 0 );
  console.timeEnd("drawImage "+X);
  }
</script>
</body></html>
------------------------------------------------------------

1. view document under Windows Chrome
2. click 5 times each (slowly) on draw1, draw2, draw3 links
3. console results attached

RESULT: Demonstrates that Chrome has a GPU bug in drawImage()
test2-results.jpg
56.3 KB View Download
And for comparison, with --disable-accelerated-2d-canvas, ms times are still very fast (attached).
test2-no-gpu.jpg
32.5 KB View Download
Cc: bsalomon@chromium.org
Owner: bsalomon@chromium.org
Status: Fixed
Fixed in r231011, including the latest Chrome Canary.
Chrome Canary 33.0.1701.0 fixes the test posted Oct 18, 2013.

It does not fix the original test when a 16291x2957 photo is resized to fit into the height of a 800x600 canvas (zoom of 0.203, 600/2957).
Status: Available
Re-opening for further investigation.
static const size_t kMaxGaneshTextureCacheBytes = 96 * 1024 * 1024???
Labels: Hotlist-Status-Auto-Corrected
Status: Assigned
Issue has owner, setting Status to Assigned.

Comment 24 by tkent@chromium.org, Jul 15 2015

Labels: -Cr-Blink-Performance Performance
Is there a status update on this issue?
Mergedinto: 464835
Status: Duplicate
There is an effort by junov@ to dynamically size the cache based on available memory. That's tracked in 464835. I'm going to dupe this into that bug since it seems like the same set of issues and that Issue is active.

Sign in to add a comment