Open Bug 1304391 Opened 3 years ago Updated 2 years ago
could you provide a live testcase?
Here's a simple test case. Click the buttons with a performance recording active and examine the results. Oddly I am seeing two different behaviours from Firefox here. Sometimes it loads the images right away (img.complete set directly), and sometimes I need to wait for the load event. I'm not sure what triggers it. I added a level of indirection via setTimeout(), but it doesn't seem to have much effect.
Status: UNCONFIRMED → NEW
Component: Untriaged → DOM
Ever confirmed: true
Product: Firefox → Core
Edgar might be able to shed some lights here...
(In reply to Pierre Ossman from comment #2) > Created attachment 8793641 [details] > load.html > > Sometimes it loads the images right away (img.complete set directly), If we could find image in cache (image has already been requested), then we load image from cache and set img.complete directly. > and sometimes I need to wait for the load event. Otherwise, we need to start a request to load image, and we set img.complete after image is loaded completely (happens asynchronously). In both cases, we fire load event.
(In reply to Edgar Chen [:edgar][:echen] from comment #4) > > If we could find image in cache (image has already been requested), then we > load image from cache and set img.complete directly. > I take it data uri images are also cached then, given that I seen this effect in the attached test? It's a bit odd that I sometimes have to wait for a load event though. Can it get evicted from the cache that quickly? > > Otherwise, we need to start a request to load image, and we set img.complete > after image is loaded completely (happens asynchronously). > Which is annoying, but acceptable. What is not acceptable is the long delay before the event. The image does not take that long to decode so it seems something is being polled rather than firing once there is something to do.
Maybe jdm has thoughts on the delay mentioned in comment 5?
Priority: -- → P3
Any ideas? I played around with the performance test tool in noVNC which tries to run a Websocket data stream recording as fast as possible. In this I added instrumentation for how long it takes for the "load" event to fire. The mean value was as follows: Chrome 54 on Fedora 24: ~1.5 ms Firefox 49 on Fedora 24: ~4 ms Chromium 54 on RHEL 6: ~1.5 ms Firefox ESR 45 on RHEL 6: ~12 ms These differences probably account for the difference in time it takes to perform the entire test, which takes ~2x longer on Fedora, and ~5x longer on RHEL. Bug 1312701 might also affect things though. Also note that Chrome tends to not require us to wait on the "load" event, so it may be even faster than the numbers here suggest.
I've been playing with my modified testcase, and the longest set of delays I've observed ranges from 15ms to 27ms as described.
Which is to say, in one single run (that loads 10 images), the shortest delay was 15ms, and the longest was 27ms.
(In reply to Pierre Ossman from comment #7) > > These differences probably account for the difference in time it takes to > perform the entire test, which takes ~2x longer on Fedora, and ~5x longer on > RHEL. Bug 1312701 might also affect things though. Clarification: The entire test takes 2x/5x longer for Firefox compared to Chrome. E.g. 14 seconds instead of 7 seconds. :)
Presumably the problem here is that images with data URLs go through our usual async channel setup. That means at least three queued runnables (OnStartRequest, OnDataAvailable, OnStopRequest), and if there's a separate thread for decoding then that requires some more asynchronous operations.
Improved test case that ensures we get a print for every image in the async complete case, shows the order in which they complete and the time taken for individual images (not just in aggregate).
There is bug 1092837 to remove the async-ness for data and blob uris.
You need to log in before you can comment on or make changes to this bug.