Issue metadata
Sign in to add a comment
|
Compositing a large Indexed PNG is very slow
Reported by
is...@instrumental.com,
Nov 1 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.75 Safari/537.36 Steps to reproduce the problem: 1. Load https://jsfiddle.net/LkoqhhLb/ 2. Start recording in the Performance tab of Dev Tools 3. Note pinned CPU, low FPS, and lots of compositing What is the expected behavior? Image renders quickly; compare to https://jsfiddle.net/t3vm2hg1/1/ which is the exact same example except the image is not indexed What went wrong? Recently I started noticing that a web app I work on was getting really slow. After a lot of debugging, a colleague and I narrowed it down to the fact that Chrome was taking a really long time to composite a default image we were displaying while waiting for other images to load. This doesn't happen in Firefox or Chrome. I suspect that this started happening a few Chrome versions back, but can't confirm - it's possible I just hadn't noticed the slowness before. Did this work before? Yes Chrome version: 62.0.3202.75 Channel: stable OS Version: OS X 10.12.6 Flash Version:
,
Nov 1 2017
Whoops, I think I mis-diagnosed this issue and posted too soon. Looks like what was actually happening is that Chrome doesn't keep 36MP decoded images in memory (24MP seems fine - not sure what the cutoff is, but it's somewhere in between). So when I was trying to render the 36MP image every frame, it had to be decoded first, and of course that is slow. I think it would be sufficient to have a console warning or something to help developers avoid going down a long rabbit hole... I get why this limit is in place. Personally I think I've solved it for my use case by switching to SVG, which seems to not have this limitation.
,
Nov 2 2017
As the issue seems to resolved, we are closing the issue as Won't fix |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by ligim...@chromium.org
, Nov 1 2017