Closed Bug 4957 Opened 26 years ago Closed 25 years ago

{perf} Big files make layout really buggy and slow.

Categories

(Core :: Layout, defect, P3)

x86
Windows 98
defect

Tracking

()

VERIFIED DUPLICATE of bug 6048

People

(Reporter: magnus, Assigned: buster)

References

()

Details

(Whiteboard: [Perf])

I was trying out viewer and apprunner at my c64 music page ( http://sid.genline.nu ) is has an very large indexfile. The layout engine shows nasty graphicsbugs. I don't know why. The rendering takes like 30seconds+ on my dual pII 400mhz which is s l o w.
It's not too surprising, because we haven't yet optimized for really large files and this file is 880K. Kipp, there are two problems. The first is a known problem, that we don't flush the content sink until the outer-most UL (of which all the remaining content is nested) is complete. That means nothing displays until the entire document has loaded. Once that problem is fixed, we can visit the second problem, which is that it scrolls very very slowly.
Severity: major → normal
Status: NEW → ASSIGNED
Target Milestone: M6
Summary: Big files makes layout rally buggy and slow. → {perf} Big files make layout really buggy and slow.
*** Bug 6513 has been marked as a duplicate of this bug. ***
Summary: {perf} Big files make layout really buggy and slow. → Big files make layout really buggy and slow.
Whiteboard: [Perf]
*** Bug 8160 has been marked as a duplicate of this bug. ***
Blocks: 8691
Severity: normal → major
Priority: P3 → P5
Summary: Big files make layout really buggy and slow. → {perf} Big files make layout really buggy and slow.
Severity: major → normal
Just verifying that this page still loads very slow and also scrolls very slow. I am using a PentiumPro 200 with 64MB RAM running Win98 and i used the latest NECKO build 1999080508...and it took 50+ seconds to load.
Well the gfx bugs are sure gone (has been 4 a while now). I'm using build 1999091310. The scrolling is much faster, but resize is still too slow. Another bug i found out with this page is that the progressbar is "done" after the html file (http://sid.genline.nu/index.html) containing the frameset (<1Kb) is loaded, but the frame that contains the most data is still loading.... Should i file a new bug on this one???
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
I only need one open bug for the large file reflow speed issue; please do file a bug against the browser group about the progressbar issue. Thanks. *** This bug has been marked as a duplicate of 6048 ***
Status: RESOLVED → VERIFIED
Marking as verified duplicate of 6048.
Target Milestone: M17 → M10
You need to log in before you can comment on or make changes to this bug.