Closed
Bug 133132
Opened 22 years ago
Closed 16 years ago
Window & chrome redraw, black & white image, and cache problem
Categories
(Core Graveyard :: GFX: Win32, defect, P1)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: schapel, Unassigned)
References
Details
(Keywords: topembed)
Attachments
(2 files)
Usually after a few hours of browsing with Mozilla on my laptop, Mozilla windows start acting strangely. The main problem is that some or all areas stop being refreshed or redrawn when the content change or when the window is uncovered. For example, sometimes most of the chrome disappears, but reappears when I move the mouse over it. Sometimes the whole window stops redrawing, and when I go to a new page I must scroll down the page or use the mouse to select text on the page to see it. Often when this happens, images start being drawn in black-and-white -- not just greyscale but literally just extremely high contrast with black or white pixels only. I will try to attach some screenshots the next time this happens. When Mozilla starts acting like I've described, I can go to File|Preferences...|Advanced|Cache to clear the memory cache. Usually, this fixes all the behavior I've described. This fix often works a few times, then stops working. Then, I must restart the computer to fix the problem. It seems like Mozilla's memory cache gets corrupted and clearing the cache can usually fix the problem. I've had this problem with builds from about the past two months, up to and including build 2002032203. This problem happens only with Mozilla and it's the only major problem I've been having (with Mozilla or any other program on my laptop) recently apart from rare crashes. My laptop is the only computer I've used during this time, so I can't say that I have or haven't had the problem on any other computer.
Reporter | ||
Comment 1•22 years ago
|
||
Here's a screenshot of the redraw problem I took last week. For some reason, the screenshot is black & white. I tried to get another screenshot, but I haven't experienced the problem since, until I tried 1.0 Release Candidate 1. Perhaps the bug was fixed on the trunk but not on the branch.
Comment 2•22 years ago
|
||
Sounds like a GDI problem. I've seen this in various other applications, usually when I'm screwing around with GDI in VC++ or VB. I think this has to do with grabbing handles to the desktop and such, and not releasing them properly, which ends up causing DC's then created to end up as black-and-white. Oh well, just speculation - this sure is weird. :)
Reporter | ||
Comment 3•22 years ago
|
||
Whatever the problem is, it happened again with trunk builds 2002042303 and 2002042603 recently. If it is a GDI problem, what Component should this bug be assigned to?
Reporter | ||
Comment 4•22 years ago
|
||
Bug 130746, bug 137410 and bug 139538 seem to describe the same problem, also with Windows 98. The comments in those bugs ask the user to reinstall Mozilla (including creating a new profile), and list the graphics card used. I have reinstalled Mozilla twice, and I still experience the problem with the latest nightly trunk builds. I'm using a Dell Inspiron 3500 with a factory installed NeoMagic MagicMedia 256AV.
Comment 5•22 years ago
|
||
I also see this on Win98 with the 2002051008 build, even after a clean install. I use a Diamond Viper V770Ultra card. I don't get the chrome turning B/W like the screenshot in this bug, but it does sporadically happen to page graphics. I usually see the "refusing to redraw" problem begin when opening a new tab, if that helps.
Comment 6•22 years ago
|
||
*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 7•22 years ago
|
||
> I don't get the chrome turning B/W like the screenshot in this bug... The chrome wasn't B/W when I took the screenshot... this bug also causes captured screenshots to become all B/W. In bug 130746, the reporter took "screenshots" with a videocam! ;-)
Reporter | ||
Comment 8•22 years ago
|
||
Updating summary to match similar bugs so this one can be found more easily, and nominating for Mozilla 1.1
Keywords: mozilla1.1
Summary: Memory cache and window redraw or refresh problem → Window & chrome redraw, black & white image, and cache problem
Comment 9•22 years ago
|
||
Since I've also been bitten by this bug on Win98SE using a Geforce 2 graphics card, here's how I was able to reproduce it: 1. Go to http://www.heise.de/newsticker/foren/go.shtml?flat=1&hs=432&forum_id=27184 2. Click on the link to the last message, "Lizenzbruch" 3. Position the mouse cursor over "Nächster" (next) in the navigation bar right above "Lizenzbruch" 4. Start clicking away on the same spot - upon clicking the link, wait till the status bar shows that the next page has begun loading, then start hammering on the left mouse button to immediately click the next link as soon as it appears 5. Repeat step 4 50-100 times, then try maximising the window or hitting F11 to go to full screen mode, or just resize the window Expected result: Mozilla should redraw the whole chrome upon resizing Actual result: In most cases, only the page contents and the favicon will be redrawn over what other windows were on the screen (I'd love to provide a screenshot, but as mentioned before, as soon as the bug kicks in, taking a screenshot is getting problematic... :( )
Comment 10•22 years ago
|
||
*** Bug 137410 has been marked as a duplicate of this bug. ***
Comment 11•22 years ago
|
||
*** Bug 130746 has been marked as a duplicate of this bug. ***
Comment 12•22 years ago
|
||
imagelib or widgets.
Assignee: gordon → dcone
Component: Networking: Cache → XP Toolkit/Widgets
QA Contact: tever → timeless
Comment 13•22 years ago
|
||
I've got a GeForce2 card as well, the Ti version, and have regularly come across this bug too. In playing around I found that the screen resolution and color bit depth had a hand to play in what was happening. To reliably reproduce this bug on at least a Win98 system, set the screen resolution to 1280x1024 and the bit-depth to 32-bit color. Load up a page and with the window unmaximised (normal) with the window to the top left. The left and top borders should be near the top left of the screen, while the right and bottom border should be at the halfway mark of the screen.This position is unimportant so far as the results go, but it does make observin the results of the test a lot easier. With the top left near the edge of the screen, drag the bottom right corner around to different places. You will observe that the chrome breaks in relation to how big the window is. With a half-height window it doesn't appear to break. When it's 3/4 of the screen height it breaks, and when the window is the full height of the screen it breaks at about half the width. If you are increasing the window size to the right you will see the mozilla icon on the toolbar stop moving. If you are increasing the window size in a downward direction you will see the status bar lose its information. There appears to be a correlation in how many resources are required to show the information for the window. A tall window breaks much more readily than a narrow one when they have their width adjusted.
Comment 14•22 years ago
|
||
I hadn't noticed this for several builds, but I see it again in Build 2002092608, win98. I also have a GeForce2, and I get exactly the behavior that Paul mentions - works in 16 bit, chrome and content draw loses it in 32bit above a certain window size.
Comment 15•22 years ago
|
||
Again, hadn't seen this (or at least it was a minimal effect, like just a few buttons) for several builds. Just loaded 2002101612 and it is back in full action, causing the entire window to go transparent/unresponsive, even on first load at the stored default size/position. Again, this is in 32 bit mode, and only above a certain window size. Manually scrolling forces a redraw, as does placing another window in front and then moving it. Why did this come back?
Updated•22 years ago
|
Priority: -- → P1
Target Milestone: --- → mozilla1.3alpha
Comment 16•22 years ago
|
||
Installed the latest Nvidia generic drivers - the size of the window no longer seems to matter, and it takes a lot longer to corrupt now, but after many windows and many pages, the chrome and page images eventually start corrupting by overwriting new images on top of old.
Reporter | ||
Comment 17•22 years ago
|
||
Bug 153864 might be a dupe or related to this bug.
Comment 18•22 years ago
|
||
Continuing from bug 153864: Yes this is the bug I'm seeing, with 2003012417. I too have a NVidia Geforce 2 card, running in 1152x864 32-bit mode, and see the chrome refresh problems. Yet only with starting with 2003012417 (I updated that from something around 20030110ish), I've never had any problems before.
Comment 19•22 years ago
|
||
This reappeared lately. It improves running 16 bit color vs 32 bit, and perhaps is postponed by turning off some of the win98 gewgaws (animate window resize, show window contents while dragging), but it's back in 2003020204 and several previous builds over the past few weeks. win98se, geforce2 MX, recent drivers.
Comment 20•21 years ago
|
||
This is still present in 1.3 final (20030312) and has become worse since 1.2.1 i.e. the problem happens after much less time. OS: Win 98 SE Graphics Card: NVIDIA Vanta PCI 32MB, BIOS 2.05.17.03 Video Driver Version: Creative 4.13.01.2832 Screen res: 1600x1200 Bit Depth: 32bit Mozilla window size: 800x1200
Comment 21•21 years ago
|
||
Is it me or is it getting worse? I'm on 2003050108, and opening 5-6 tabs and surfing around for ~10mins (!), I start seeing the effects mentioned by others in this bug. It affects all mozilla windows, not only the browser window. Can someone change the target milestone and perhaps up the severity?
Comment 22•21 years ago
|
||
Finally got a non-black-and-white image of the bug i'm seeing. Is this similar to what others are seeing?
Reporter | ||
Comment 24•21 years ago
|
||
> Is it me or is it getting worse?
I'm seeing some sort of other problem with Mozilla recently. Mozilla and other
programs report "Out of Memory" errors, and fonts and graphics get corrupted in
all programs. Quitting programs temporarily makes the symptoms go away. This new
problem seems to be quite different from this bug.
Comment 25•21 years ago
|
||
I've had the problem shown in Mark's screenshot It's appeared in both the browser and mail client I think it happens when i have quite a lot of tabs open and having other non-mozilla apps open may have contributed so it may be memory related. I think the last two times this happened, it was actually triggered when I tried to access a menu in either the browser or mail client. Then areas would fail to redraw as described in the original bug description and i'd get those black lines round things. Im using Mozilla v1.4b under win98 I dont think i experienced this with previous milestone builds
Reporter | ||
Comment 26•21 years ago
|
||
If you can get a color screenshot, if the problem never goes away when you clear the cache, and if you can get the problem to go away by closing other open applications, it likely isn't this bug. The "out of memory" bug described above has been fixed in the latest nightlies, both on the trunk and the 1.4 branch.
Updated•21 years ago
|
Flags: blocking1.4?
Keywords: mozilla1.1
Comment 27•21 years ago
|
||
dcone is no longer working on this. any other willing to take this?
Keywords: topembed
Comment 28•21 years ago
|
||
The last comments seem to refer to bug 204374 . Is this a dupe ?
Reporter | ||
Comment 29•21 years ago
|
||
> The last comments seem to refer to bug 204374 . Is this a dupe ? I don't think so. The symptoms of the two bugs seem completely distinct to me. I still do experience bug 204374 -- this might have been the cause for the "Out of Memory" errors I was getting, but I no longer get those error messages, just the font and graphics corruption. But unlike this bug, that bug goes away when I close other applications.
Comment 30•21 years ago
|
||
The bug in action with latest stable 1.4 (win32) at: http://andreas.sparcy.net/mozbug/ Windows XP SP1 with loads of applications running. If I end most of them, Mozilla will work fine for a while but then after 2-3 hours of heavy surfing and 10-15 tabs open I have to restart it.
Flags: blocking1.4?
Comment 32•21 years ago
|
||
The quick test to see if this is a dup of bug 204374 -have only one window (no extra tabs) open -type in and goto the url "about:blank" -clear cache (Edit->Preferences->Advanced->Cache => Clear Cache) -type in "about:config", scroll down to "browser.cache.memory.enable" click on it, change "true" to "false". surf... do you still see the problem? if not then I am 99.9% sure this is a dup of but 204374
Comment 33•21 years ago
|
||
Yes, it's still there. I tried opening a page with about 100 1280x1024 JPEG images and the problem still persists.
Comment 34•21 years ago
|
||
I am getting the same redraw problem discussed in this thread: Win98, physical memory: 654Mb, resources: 27%free ATI Radeon7500 video card, BIOS: 2001/09/28 Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 I'll try upgrading the BIOS to see if that helps.
Comment 35•21 years ago
|
||
from comment #33, if you open 100 1k by 1k images you may run into this. BTW I have a patch being looked at in bug 205893, awaiting review. just as one more test, can you bring up Resource Meter after you have loaded the 100 images and the screen starts to flake out and tell me the % you are seeing To run Resource Meter: Start->Programs->Accessories->Systems Tools->Resource Meter This will add an icon to your active programs, click on it and let me know what your % free of each of the 3 things are. Thanks
Comment 36•21 years ago
|
||
Sorry, it's Windows XP and there is no resource meter there. I could check User/GDI objects in taskmgr if it would help?
Reporter | ||
Comment 37•19 years ago
|
||
(In reply to comment #33) > Yes, it's still there. I tried opening a page with about 100 1280x1024 JPEG > images and the problem still persists. Can you give some steps to reproduce? I just created a page with 100 1280x1024 JPEG images, and when I viewed it I saw no problems using SeaMonkey 1.0. It's currently using about 300 GDI objects, which doesn't seem excessive.
Reporter | ||
Comment 38•18 years ago
|
||
Bug 284978 looks like a similar bug relating to GDI usage and repainting.
Assignee: jdunn → win32
Component: XP Toolkit/Widgets → GFX: Win32
QA Contact: timeless → ian
Reporter | ||
Updated•16 years ago
|
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Updated•16 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•