216271 - large table with images in many cells is very slow compared with IE

Status: RESOLVED INVALID

(Core :: Layout: Tables, defect)

Description

[Michael G. Katzmann]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030718
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030718

If a table is rendered with many images in the cells, even if the images are the
same file, it takes an order of magnitude longer to display than IE.

To check create a table with, say 40 rows and 10 columns and place the same
small (16x16) image in each. On my 2GHz machine under W2000 it takes 3 seconds
to display. With IE, it is instant (< 100ms). 

Reproducible: Always

Steps to Reproduce:
1. Create table 40 rows by 10 columns with same image in each cell
2. load
3. reload and see delay.

Comment 1

[Michael G. Katzmann]

Attachment: Test file with table

Use this file with the gif image also to check delay

Comment 2

[Michael G. Katzmann]

Attachment: image file for testing table with images

Comment 3

[Bernd]

Attachment: revised testcase linking the images

Comment 4

[Jesiah S]

I notice no real diffrence between IE6 and Moz W2K 2003081904
Both took ~4s to reload.
When I saved it to the local drive. IE was about twice as fast as Mozilla which
took about a 2s.
PII400

Comment 5

[Michael G. Katzmann]

Well, I wouldn't use the "revised test case", since it also has to execute
http://bugzilla.mozilla.org/attachment.cgi?id=129861&action=view
which adds error.  
Download the page and image. (although, it doesn't seem to effect the time if
just the page is loaded (with broken images).

On W2K and W98 IE6, the page loads, for all intents and purposes, instantly.
On my 1.6 GHz machine with Moz 1.5b W2K more than 3 sec. On a 266 MHz it's more
than 10 sec.

Comment 6

[Michael G. Katzmann]

I think this is ACTUALLY a bug in the "adblock" plugin. I tried a virgin
installation without any add-ons and the page loaded in about a second, but with
the Adblock 0.4 d60 (latest development version) it took 4 seconds.

Comment 7

[Michael G. Katzmann]

Rue of the adblock development group says...
   quote
yes, that's the result of the current design. as each element is bound, it fires
a keypress event with element-specific charcodes. adblock's chrome-priveleged
listener catches this and then filters the image. there's overhead to the
keypress event which, unfortunately, is necessary.

an alternate method is being tested, though. it uses xpcom to hook directly into
content-policy system and the overhead will then be negligible. it's not here
yet, but it's coming...
    unquote

So the bug should be marked "invalid"