Slower image rendering

REOPENED
Unassigned

Status

()

Core
ImageLib
REOPENED
8 years ago
10 months ago

People

(Reporter: Martijn Wargers (dead), Unassigned)

Tracking

({regression, testcase})

5 Branch
x86
Windows 7
regression, testcase
Points:
---

Firefox Tracking Flags

(blocking2.0 -)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

8 years ago
See url, in current trunk build, the loading of that large image seems to be happening much slower than normally.
This regressed between 2010-08-17 and 2010-08-19:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2010-08-17+04%3A00%3A00&enddate=2010-08-19+04%3A00%3A00
I guess a regression from bug 512260.
blocking2.0: --- → ?
Can you confirm that this definitely happened in that range? On face this would seem much more likely to be related to bug 563088 (pushed friday night) or bug 513681 (pushed saturday night). If you can confirm that this definitely happened before then, it would be very useful.
When you say slow, how much slower do you mean? It loads in a reasonable amount of time for me on Linux, at least.
(Reporter)

Comment 3

8 years ago
Created attachment 468494 [details]
testcase

It turns out I was wrong with my regression range.

With this testcase, I get as result:
Firefox3.6.8: 4180ms
20100820 trunk build: 7659ms
20100821 trunk build: 9848ms
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2010-08-20+04%3A00%3A00&enddate=2010-08-21+05%3A00%3A00

With this testcase, the slower rendering typically seems to happen on reload. So the numbers are for reload. With the slower rendering, the images become visible in chunks.

Btw, Opera10.61 seems to be really quick, I get there as test result: 2713ms.
The range in comment 3 has bug 563088 in it.  That makes some sense, though I'm not sure why decoding after discard would be slower than decoding up front....
Blocks: 563088
No longer blocks: 512260
(In reply to comment #4)
> The range in comment 3 has bug 563088 in it.  That makes some sense, though I'm
> not sure why decoding after discard would be slower than decoding up front....

It is very much slower, probably because we decode such small chunks at a time. I'm working on it.
(Note for Boris)

When we redecode after discard, we only send the decoder 8k of data at a time, and then we check the time to see if 5ms has elapsed. When we decode for the first time, though, we just let necko send us as much data as it pleases. That's why it's slower right now to redecode.
Joe - you were right on IRC - it's actually 4k.

I just hacked together a build that sends bigger chunks and has a longer time threshold and only invalidates at the end. It's much more pleasant to use I think. I'll turn it into real patches tomorrow.
blocking2.0: ? → betaN+
I think Bobby already did this in another bug!
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 9

7 years ago
The rendering in chunks bug is indeed fixed, it seems, but rendering time on trunk with the testcase is still appr. 2 times as slow as Firefox3.5 on my computer.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
For me, trunk is about 2000 ms compared to about 35000 ms on 3.6. On the other hand, chrome and safari are at about 200 ms. So we're certainly being slow here, but I can't reproduce this as a regression per se.

Can you reproduce this without using data-urls? What I'm guessing is happening is that the cache isn't coalescing requests with the same data URL, which means that we decode the png 12 times while chrome/safari decode it once (this would satisfy a roughly linear relation in the load times).

If this is indeed limited to data-urls, we should keep this bug open (and rename it), but probably not block on it.
(In reply to comment #10)
> For me, trunk is about 2000 ms compared to about 35000 ms on 3.6.

And by that I mean 3500 ms. 3.5 seconds, not 35 seconds.
If this is only data urls, I think we can live with it for now.
blocking2.0: betaN+ → -
(Reporter)

Comment 13

7 years ago
Why do you think it's only for data urls?
Bobby suggested so in comment 10, and asked for confirmation. Please renom if this isn't the case.
Does the image cache, or decoders, support logging of some sort?  It should be trivial to test the theory in comment 10 if so (and if someone tells me or Martijn what to log).
(In reply to comment #15)
> Does the image cache, or decoders, support logging of some sort?  It should be
> trivial to test the theory in comment 10 if so (and if someone tells me or
> Martijn what to log).

Yes. NSPR_LOG_MODULES=imgRequest:5 ./firefox
Created attachment 482688 [details]
Resulting log file (zipped plaintext)

Note that this is using <iframe>s, so not even taking the normal image-loading codepath in general....
(Reporter)

Comment 18

6 years ago
This is still an issue in current trunk build. In fact, performance might be even worse now.

Comment 19

6 years ago
I think the problem is still here. And I'm experiencing it also by embedding font-face in data URL. If it's not very difficult to fix, I think it shoudl be a good idea to do it as data URL are often used in modern HTML5 apps.
Version: Trunk → 5 Branch
(Reporter)

Updated

10 months ago
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago10 months ago
Resolution: --- → WORKSFORME
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
You need to log in before you can comment on or make changes to this bug.