589822 - Slower image rendering

Status: REOPENED

(Core :: Graphics: ImageLib, defect)

Description

[Martijn Wargers (dead)]

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.

Comment 1

[Bobby Holley (:bholley)]

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.

Comment 2

[Joe Drew (not getting mail)]

When you say slow, how much slower do you mean? It loads in a reasonable amount of time for me on Linux, at least.

Comment 3

[Martijn Wargers (dead)]

Attachment: 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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

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

Comment 5

[Bobby Holley (:bholley)]

(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.

Comment 6

[Joe Drew (not getting mail)]

(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.

Comment 7

[Bobby Holley (:bholley)]

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.

Comment 8

[Joe Drew (not getting mail)]

I think Bobby already did this in another bug!

Comment 9

[Martijn Wargers (dead)]

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.

Comment 10

[Bobby Holley (:bholley)]

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.

Comment 11

[Bobby Holley (:bholley)]

(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.

Comment 12

[Joe Drew (not getting mail)]

If this is only data urls, I think we can live with it for now.

Comment 13

[Martijn Wargers (dead)]

Why do you think it's only for data urls?

Comment 14

[Joe Drew (not getting mail)]

Bobby suggested so in comment 10, and asked for confirmation. Please renom if this isn't the case.

Comment 15

[Boris Zbarsky [:bzbarsky]]

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).

Comment 16

[Bobby Holley (:bholley)]

(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

Comment 17

[Boris Zbarsky [:bzbarsky]]

Attachment: Resulting log file (zipped plaintext)

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

Comment 18

[Martijn Wargers (dead)]

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

Comment 19

[bruno.michel]

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.