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

Issue 877083 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug

Blocked on: View detail
issue 731586
issue 831740



Sign in to add a comment

Blob and createImageBitmap slow

Reported by oss...@cendio.com, Aug 23

Issue description

UserAgent: 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.
 
Components: Blink>Canvas
Labels: Needs-Triage-M68
Cc: krajshree@chromium.org
Labels: Triaged-ET Needs-Feedback
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...!!
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).
Project Member

Comment 5 by sheriffbot@chromium.org, Aug 24

Labels: -Needs-Feedback
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
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 
imagebitmap.html
6.3 KB View Download
Cc: phanindra.mandapaka@chromium.org
Labels: Needs-Feedback
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.!
877083.png
275 KB View Download
Blockedon: 731586 831740
Cc: fs...@chromium.org
Status: Available (was: Unconfirmed)
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.


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?
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