Blob and createImageBitmap slow
Reported by
oss...@cendio.com,
Aug 23
|
|||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36 Steps to reproduce the problem: Replace code using Image() and base64 encoding of JPEG data, with code using Blob() and createImageBitmap(). What is the expected behavior? Performance improvement by using more direct APIs. What went wrong? Performance regressed massively. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 68.0.3440.106 Channel: stable OS Version: Flash Version: On Firefox this results in a massive performance boost, so this code change is highly desirable. I would prefer to not black list Chrome based on user agent, but I'm not sure what other options there are. The profiler also misbehaves when testing this as it causes massively more overhead for the Image case than the Blob/ImageBitmap case. It is therefore difficult to pinpoint the problem. However the Blob constructor accounts for 30% of the test run, and createImageBitmap() for another 23% so they are the likely suspects. ⛆ |
|
|
,
Aug 23
,
Aug 24
ossman@ - Thanks for filing the issue...!! Could you please provide a sample test file/url to test the issue from TE-end. This will help us in triaging the issue further. Thanks...!!
,
Aug 24
I will try to put something together. Right now I've been testing with noVNC's vnc_playback.html performance tool. But that is rather complex (it does show a real world case though).
,
Aug 24
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 24
Self contained test case. This uses almost the same method as the full test case in noVNC. On my machine here I can see these numbers for Chrome: Image performance: 77 ms ImageBitmap performance: 554 ms For Firefox though: Image performance: 155 ms ImageBitmap performance: 124 ms
,
Aug 27
Tried to reproduce the issue on reported chrome version 68.0.3440.106 and latest chrome 70.0.3534.0 using Ubuntu 17.10. Attaching screenshot for reference. Steps: --------- 1. Launched reported chrome 2. As per comment #6 Downloaded the html file 3. Opened html file in new tab As we have observed the Image performance and ImageBitmap performance, values as per screenshot. @Reporter : Can you please review the attached screenshot and confirm the issue. Observed near values form M-60 to latest chrome 70.0.3534.0. Thanks.!
,
Aug 27
On your benchmark, if you replace:
img.src = "data: image/jpeg;base64," + jpeg_b64;
with:
let blob = new Blob([jpeg], { type: "image/jpeg" });
img.src = URL.createObjectURL(blob);
I get the following results:
Chrome:
Image performance: 1072 ms
ImageBitmap performance: 579 ms
Firefox:
Image performance: 1270 ms
ImageBitmap performance: 174 ms
If you move the blob creation outside:
Chrome:
Image performance: 876 ms
ImageBitmap performance: 493 ms
Firefox:
Image performance: 194 ms
ImageBitmap performance: 184 ms
If you also move URL creation outside:
Chrome:
Image performance: 105 ms
ImageBitmap performance: 533 ms
Firefox:
Image performance: 180 ms
ImageBitmap performance: 172 ms
This tells me that:
- URL.createObjectURL() performance is much worst in Chrome. (blocking on 731586 for this).
- ImageBitmap performance is bad. I'm almost sure this is due to 831740.
So although I think there's nothing direct for us to do right now, I'll leave this bug open with those two blockers.
Once we solve those, we can reassess how this benchmark goes.
,
Aug 28
Thank you for that analysis. I don't suppose you have any nice idea on how a web application can detect these performance issues and decide which code path to use?
,
Aug 28
Hmmm... reading 831740 and the suggested patch, it sounds like that bug is about an issue that is specific to a WebGL context, and not a 2D one? The patch even suggests that it will improve things for WebGL at the cost of 2D. |
||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by dtapu...@chromium.org
, Aug 23