Closed
Bug 6048
Opened 25 years ago
Closed 25 years ago
[PP] {perf} Layout of large HTML files goes wrong
Categories
(Core :: Layout, defect, P3)
Tracking
()
VERIFIED
FIXED
M11
People
(Reporter: erik, Assigned: buster)
References
()
Details
(Whiteboard: [Perf])
Attachments
(4 files)
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.
Chris -- can you please test this on NT ad 9x, and let me know how prolific the problem is?
Updated•25 years ago
|
Assignee: chrisd → rickg
QA Contact: 4144 → 4110
Summary: Layout of large HTML files goes wrong → [PP]Layout of large HTML files goes wrong
Comment 2•25 years ago
|
||
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.
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.
Status: NEW → ASSIGNED
Summary: [PP]Layout of large HTML files goes wrong → {perf} [PP]Layout of large HTML files goes wrong
Target Milestone: M15
Summary: {perf} [PP]Layout of large HTML files goes wrong → [PP]Layout of large HTML files goes wrong
Whiteboard: [Perf]
See bug 1177 for other (compositor) problems with long documents.
Comment 8•25 years ago
|
||
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•25 years ago
|
||
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•25 years ago
|
||
Comment 11•25 years ago
|
||
Comment 12•25 years ago
|
||
Comment 13•25 years ago
|
||
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.
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.
Summary: [PP]Layout of large HTML files goes wrong → [PP] {perf} Layout of large HTML files goes wrong
Target Milestone: M17 → M12
Comment 16•25 years ago
|
||
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•25 years ago
|
||
*** Bug 4957 has been marked as a duplicate of this bug. ***
Comment 18•25 years ago
|
||
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•25 years ago
|
||
chrisd, can you verify?
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 20•25 years ago
|
||
Using build 1999110309 on Linux. Page loads and scrolls with no corruption. Verifying bug fixed.
Comment 21•25 years ago
|
||
*** Bug 18495 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•