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

Issue 652488 link

Starred by 2 users
Status: Archived
Merged: issue 664615
Owner: ----
Closed: Sep 27
Cc:
xidac...@chromium.org
█ mbarowsky+gpuimage@chromium.org
andrescj@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Long Image Decode when drawing large image to canvas

Reported by mpariz...@pdftron.com, Oct 3 2016 
UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36

Steps to reproduce the problem:
1. Navigate to http://pdftron.com/webviewer/bugdemo/
2. Press the button that looks like a magnifying glass with a plus sign to zoom in.
3. Notice the several second delay where Chrome is frozen.

What is the expected behavior?
If you compare the behavior to Firefox or even IE11 there is no several second delay between zooms.

What went wrong?
The document being rendered contains a very large image 20555 x 7239 pixels that is being drawn to the canvas. When I use the timeline view to profile I see a several second Image Decode and then a bunch of activity on the GPU.

Did this work before? N/A 

Chrome version: 53.0.2785.116  Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 23.0 r0

Comment 1 by pierre.d...@gmail.com, Oct 24 2016 

I can confirm some pretty long Image Decode when cropping a sprite (its dimensions is around 1000*16000).

The crop with drawImage() randomly takes 40/60ms, when it's usually 2/4ms.

Comment 2 by dtapu...@chromium.org, Nov 10 2016

Components: Blink>Canvas Blink>Image

Comment 3 by schenney@chromium.org, Nov 10 2016

Components: -Blink>Image Internals>GPU>Image
Status: Untriaged (was: Unconfirmed)
It is indeed slow on M55 Linux.

Comment 4 by xidac...@chromium.org, Nov 11 2016

Cc: xidac...@chromium.org junov@chromium.org
Status: Available (was: Untriaged)
I noticed that disabling accelerated-2d-canvas solves the problem. I think somewhere we turn off gpu acceleration for some reason. I will do some initial investigation.

Comment 5 by xidac...@chromium.org, Nov 14 2016

Cc: -junov@chromium.org
Owner: junov@chromium.org
Status: Assigned (was: Available)
junov@: could you take a look? I have attached the trace here. Gpu is not involved, I believe that is because it is trying to draw a very large image and gpu-accelerated is disabled. I don't know why the compositor takes such a long time to finish a frame.
trace.json.gz
1.4 MB Download

Comment 6 by xidac...@chromium.org, Nov 14 2016

Mergedinto: 664615
Status: Duplicate (was: Assigned)
Should be a duplicate with 664615

Comment 7 by xidac...@chromium.org, Nov 14 2016

Status: Assigned (was: Duplicate)
Un-dup, the other one is not a performance issue.

Comment 8 by pierre.d...@gmail.com, Dec 13 2016 

Still happening in Chromium 55 indeed

Comment 9 by junov@chromium.org, Jul 25

Owner: ----
Status: Available (was: Assigned)

Comment 10 by mcasas@chromium.org, Sep 27

Status: Archived (was: Available)
Archived, please reopen if appropriate.
►

Sign in to add a comment