Closed Bug 381578 Opened 18 years ago Closed 10 years ago

rendering becomes corrupt after about half of the page + images are loaded

Categories

(Core Graveyard :: GFX, defect)

x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: bugzilla.mozilla.org, Unassigned)

References

()

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070521 Minefield/3.0a5pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070521 Minefield/3.0a5pre The provided URL is a long forum topic with a huge amount of images: Documents (1 file) 118 KB Images (205 files) 11000 KB Scripts (3 files) 33 KB Style Sheets (3 files) 17 KB ----------------------------------- Total 11168 KB it takes quite some time to load all the images. Minefield works fine until about half of all the images are loaded. I can scoll up and down, jump HOME and END etc. But then, once more images get loaded, Minefield stops updating the display/rendering. I see the "position marker" on the scroll bar moving up and down when I scroll but the display remains what was visible Reproducible: Always Steps to Reproduce: 1. load given URL 2. while page is loading images scroll up and down 3. do so until you see rendering becoming corrupt The given URL loads and gets displayed fine in Firefox-2.0.0.3 and MSIE 6. Interesting observation on memory usage after loading the huge page in minefield compared to others: MSIE 6: 411MB virtual 319MB working set 310MB Private bytes Firefox 2: 418MB 353MB 342MB Minefield: 103MB 40MB 29MB (Firefox 2 with a couple of extensions loaded)
Version: unspecified → Trunk
Slight correction: not only the display but the rendering of whole UI becomes corrupt
Maybe dupe of/related to bug 366548. What's your GDI usage like at the page? (You can add it as a column to the Task Manager process list)
two further observations: I started a 2nd independent instance of minefield to report this bug but this instance seemed also affected and showed corrupt rendering. While writing the report and reading on some other bugreports in FF2, the Minefield browser window was still open and has kind of recovered a bit by now. the UI is partly working again and I can scroll the huge page again and see the content. But it seems that not all of the linked images are really loaded. Weird: although the page looks ok now when scrolling with the cursor keys or mouse, I just used FAYT to search for "Antwort", then use "F3" key and when doing so the rendering acts strange, images overlaying text, only parts of the screen get updated. As soon as I scroll normally the rendering goes back to normal. The second parallel instance also has mostly recovered but resizing any of the the two windows still leaves artifacts on screen. GDI objects in Minefield showing the huge page at this point in time: 2,120
i cannot reproduce with current nightly, do you still see that?
unfortunately the testcase is gone. Most posts of the forum topic are gone, moved to a different web site and organized in a more browser-friendly way. the size of the images is only 1/10 now Documents (1 file) 79 KB Images (62 files) 1059 KB Scripts (3 files) 33 KB Style Sheets (3 files) 11 KB Total 1182 KB I'll try to create a new testcase for this issue.
created a new test case http://www.ja-web.de/Screenshots/X-Plane/huge-page-index.php?n=1 change the "1" at the end to a higher number to get more images on the page. I tried 500 with FF-2.0.0.4 and MSIE6, booth showed the page without issues, both wehere using about 900MB Virtual memory. (The FF2 number below is with additional tabs open) A current FF-3 Nightly will load the page too and it looks ok until you start to scroll down: then the content and even the UI become corrupt (put some other window in front of FF3 and take it away) Process Explorer shows <pre> Process Virtual Size Working Set Private Bytes GDI Objects Command Line USER Objects ------------------------------------------------------------------------------------------------------------ firefox.exe 1.135.060 K 1.006.588 K 994.728 K 184 FIREFOX_2\FIREFOX.EXE 108 firefox.exe 130.152 K 51.556 K 41.220 K 1.856 firefox_3\firefox.exe 58 </pre> So, FF3 memory consumption remains rather low but GDI object count goes way up compared to FF2
changed the test page slightly to see the impact of image sizes http://www.ja-web.de/Screenshots/X-Plane/huge-page-index.php?t=1&n=1 will show number of n thumbnail images http://www.ja-web.de/Screenshots/X-Plane/huge-page-index.php?n=1 as before, shows number of n large images
i get about your same results for memory consumption and gdi objects but i don't get graphic artefacts on page or on gui
Component: General → GFX
Product: Firefox → Core
QA Contact: general → general
i can finnaly reproduce also artefacts problem, it hangs somehow and does not redraw moving a window in front of it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
bug 366548 is now fixed - can you check if tomorrow's build (20071004 or later) fixes it ?
yes, the rendering is fixed now the example from comment #6 http://www.ja-web.de/Screenshots/X-Plane/huge-page-index.php?n=500 loads and renders fine now. But the cost is an rather huge memory consumption, far more than FF2 uses in the same page (compare to comment #6) firefox3.exe 1.317.620 K (Virtual) 1.232.248 K (Working set) 1.220.096 K (private) 1.228 (GDI)
So can we now mark this bug as a dupe of bug 366548 and note that you have filed bug 398983 wrt the increase in memory usage?
Product: Core → Core Graveyard
This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX. [Mass-change filter: graveyard-wontfix-2014-09-24]
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.