6048 - [PP] {perf} Layout of large HTML files goes wrong

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[erik]

To test the layout engine, I selected a link (7.5 or something) from the above
URL which is a table of contents of a *large* html file. What I am shown is some
blue text on a black background (the previous page was blue visited links on a
black background...). I've tried it for four times or something alike, and every
time the page got messed up.

Comment 1

[rickg]

Chris -- can you please test this on NT ad 9x, and let me know how prolific the
problem is?

Comment 2

[Christine Hoffman]

Tested this page using 5/7 Apprunner on Win NT, Win 95, Win 98, Mac8.5 and
Linux. Clicked on the '7.5' link which began to load:

http://www.tcx.se/Manual/manual.html#DROP_DATABASE

Results as follows:

Win NT: Page loaded although it took about 5 min. Able to scroll to bottom
(slowly) with no problems.

Win 95, Win 98 and Linux: Page is corrupted while loading (text over text, etc).
After 20 minutes, status indicates still loading (except for Win 95 which says
'Done'). At this point I am able to scroll to the top where the display is now
clear. However, scrolling from the top, I am only able to scroll down to about
the '3.5' indicator and then the page is once again corrupted.

Mac8.5: Page is corrupted from the beginning. After 20 minutes, status indicates
that data is still being transferred. If I go to the top of the page, it is
still corrupted. This had the most buggy behavior of all platforms.

Changing 'Assigned to' to rickg and will put myself on as QA contact. Also,
changing to PP bug as this only works on Win NT.

Comment 3

[rickg]

Kipp -- this is a pathologically huge document, and it exacerbates our content
append performance issue. The other issues referred to here are likely the
result of the CPU being sucked up by layout/content append. Let's start there.

Comment 4

[leger]

putting on [Perf] radar

Comment 5

[rickg]

*** Bug 8471 has been marked as a duplicate of this bug. ***

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

See bug 1177 for other (compositor) problems with long documents.

Comment 7

[leger]

*** Bug 10004 has been marked as a duplicate of this bug. ***

Comment 8

[Eric Pollmann]

There are also memory issues associated with large files.  For example, on one
large 760K page (bug 10004), memory usage jumped from 12Mb to 72Mb while loading
and displaying the page.  This put document memory use at around eighty times
larger than file size.  (Linux, Necko apprunner from 3PM 7/27)

Comment 9

[Hervé Renault]

I think I was hit by the same problem --with a home-compiled 1999-09-02-08-M9.
Here are some screenshots. Is it what you see too ?

I noticed that this problem often arises when lots of :
 Block(body)(1)@0x831a468: WARNING: desired:8655,5898823
 nsBlockReflowContext: Block(body)(1)@0x831a468 metrics=8655,5898823!
 Area(html)(-1)@0x88a84e0: WARNING: desired:8885,5899418
appear on the console...

(heavily compressed jpeg's to save bandwidth)

Comment 10

[Hervé Renault]

Attachment: loading of http://www.fr.debian.org/Bugs/db/ix/full.html is long (3168 K)but OK

Comment 11

[Hervé Renault]

Attachment: it's OK too when you begin to scroll, but it goes wrong rapidly (see the position of the slider)

Comment 12

[Hervé Renault]

Attachment: it becomes worse when you keep on scrolling down. resizing the window does not refresh or anything.

Comment 13

[Hervé Renault]

Attachment: but when you arrive to the bottom of the document, it's clean again !

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The screenshots given look a lot like the bug 1077 problems.  Perhaps that needs
to be re-investigated.  I believe the previous solution only increased the
available space by a factor of 15 (well, actually t2p, which varies).

I'll try and look into it if I have time, which is unlikely.

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Many of the comments on this bug are really duplicates of bug 1177 / bug 2564.
However, there seem to be some performance issues here too as noted by rickg and
pollman.

There is no need to reopen bug 1177 (and certainly not 1077!!) because bug 2564
currently covers the Linux problems.

Comment 16

[kipp]

The page now renders OK (however the background doesn't paint very nicely
because of the large size of the content area; the rest does paint fine however;
bug 2564 remains the correct bug for handling the painting issue.

However, the loading time for this page is hideous. Moving up to M12 so that at
least some analysis will be done before beta.

Comment 17

[kipp]

*** Bug 4957 has been marked as a duplicate of this bug. ***

Comment 18

[kipp]

The issue here was directly related to 7455 which has been fixed. The painting
bug already has a seperate bug # so I'm closing this bug.

Comment 19

[leger]

chrisd, can you verify?

Comment 20

[Christine Hoffman]

Using build 1999110309 on Linux. Page loads and scrolls with no corruption.
Verifying bug fixed.

Comment 21

[leger]

*** Bug 18495 has been marked as a duplicate of this bug. ***