Closed Bug 20150 Opened 20 years ago Closed 20 years ago
Browsing area flashes garbage between page loads
8.54 KB, image/png
52.05 KB, image/gif
99.01 KB, image/gif
23.10 KB, image/png
Build 1999112711 Steps to recreating this bug: 1. Open Mozilla and randomly visit other pages 2. notice how the viewing area briefly flashes with garbage between page visits, kinda like TV static when changing channels.
I don't see this on NT, but that may be because of the way NT initializes memory for security reasons. This sounds like a rendering issue. Maybe we're rendering parts of the double buffer before it has been initialized?
Using the 11/30 build in win95 I get the same problem when clicking on the location bar and other text boxes. The garbage flashes in the text box and looks like the image surrounding it. Example 1. Clicking the location text box you can see the toolbar's background. This flash only occurs the first time the text box is clicked on.
*** Bug 20414 has been marked as a duplicate of this bug. ***
Moving to M15
Testing this on two different machines, one using a a 4MB ATI RAGE+ PCI video card on Win95, and the other a 32 MB ATI RAGE 128 FURY SG TV AGP2x on Win98, it looks like the severity of the problem depends on: 1. The colour bit depth 2. The specific card/driver combination I couldn't get this problem to reproduce at all on the Win98 machine at 32 bpp, but it showed up every time at 8bpp. On the Win95 machine, it was worst at 8bpp. Confirmed that this doesn't happen on NT.
I see this on a k6-200 with a pci matrox mystique running in 24-bit color on win98. It's quite severe, you really do see it. I also see it on a cel466 with tnt2ultra (agp) and 32-bit color. It is however only in the bottom half, probably because it goes so quickly it's already drawing the correct stuff. Changing the color depth on the cel466 down to 8-bit made it pretty much go away. This however could be because 8-bit is faster and I didn't see it flash so quickly. I'll do some more testing on the k6 when I use it next.
I have a theory on what this is. When you first launch mozilla, the source default for the content frame is about:blank. Then it goes through tryToSetContentWindow() js function which then goes through various switches and and checks to find the actual start up page. Thus causing some "page load confusion". This i beleive is the cause for the apparent static. I am suggesting this because i have done some experments where i removed this function entirely and had a page source hard coded in the <browser> tag. The start page loads in perfectly, nice and clean. I am in the process of rewriting these functions and others for more efficient performance. I hope to have time this week to continue this work. pete
That "garbage" showing up between page loads to me - by the way - looks exactly like the navigation toolbar. I don't know if this is the same problem, but that's whats showing up in the content area for me for a few milliseconds (just long enough to make a screen shot, by the way... my computer seems to be slow enough to see it).
Here it looks literally like static. No weird rendering of nearby chrome elemts, just pure static. It usually only occurs in a portion of the content area rather than the entirety. I see it on my AMD Athlon 650 with TNT2 Ultra, 32bpp, 1024x768 under Win98 quite well. It is very noticeable. I would estimate that it appears for .2 to .5 seconds between the loading of most pages.
Adding myself to the CC list.
Might this be a manifestation of bug #1248 ? If it generally happens on pages with a background image or within image frames (the examples I've seen), then I think that the answer is yes.
OS: Windows 98 → All
Hardware: PC → All
I can definitely confirm that Mozilla is rendering, or at least drawing itself (i.e. its whole window) into the content area for me (on 2 diff. computers). I suspect that the quick change (old page -> Mozilla window -> parts of new page) makes it look like static, or maybe the fact that Mozilla starts drawing each part of the chrome and never finishes it (?) makes it look even more like static. - if anyone wants the screenshot, let me know...
You could be right. From what I've seen it's adding an offset to this so that you get a staircase effect when it displays it though.
okay, I've been fiddling around with this a little... especially trying to get screen shots. First of all I realized that in full screen mode (sidebar off) you shouldn't get so much static, mozilla usually just draws its own window or parts of it. If the window size is smaller you obviously get an offset to the whole stuff (as phil said), so it looks more like static. this isn't limited only to content "owned" by mozilla, i often get parts of window's task bar thrown in as well, or my desktop, or things like that. interesting is that i once closed mozilla, then opened it again an hour later or so and in all the static i could see content that i had viewed with mozilla that hour earlier. so i suppose it must have grabbed that somewhere from RAM (since disk cache or anything doesnt work yet, right?) so yea, as it seems, the static is just the screen content most of the time.
On my system, it is not anything near recognizable as Mozilla chrome or page content. I will stick on a small pic approximating its appearance. It is a Photoshop hack since it happens to fast here to get a screenshot.
It's obvious by Jerry Baker's approximate rendering that this problem seems to vary depending on the machine. Although it does appear like static, mine tends to have more structure as if it's a garbled up rendering of the entire Mozilla window.
*** Bug 25715 has been marked as a duplicate of this bug. ***
*** Bug 26001 has been marked as a duplicate of this bug. ***
OK. Anyone see the new phenomena in the browser window - The flashing of page content upside down and backwards? Is this the same bug, or should I file a new one? I will post a screen capture as an attachment.
Jerry, this is actually what I've most been experiencing on my work machine. It's not particularly fast (k6-200). So the webpage upside down has been around for quite some time.
I have fix for this. The problem is in nsGfxScrollFrame.cpp. It sets attributes during the reflow of the scroll frame which causes compositing/painting to happen during the reflow. CC'ing evaughan. Moving to M14, changing priority to normal.
Severity: minor → normal
Target Milestone: M15 → M14
I'm now seeing this on my Win98 HP Laptop as of 2/1 build Adding beta1 keyword
PDT+ for B1 on this polish item
Unfortunately, my fix which prevents the GfxScrollFrame from causing a paint from within GfxScrollFrame::Reflow is not the right thing to do. The problem is the the GfxScrollFrame really needs to set the visibility of the horizontal and vertical scroll bars. It currently does this during Reflow because thats when it knows what size of it's content area is. The setting of the visibility is done by setting an attribute on the scrollbar's XUL element and using an attribute selector on a style rule in xul.css to set the visibility of the scrollbar. Here is the sequence that causes problems GfxScrollBar::Reflow(..) verticalScrollbar->SetAttribute(..) // Change it to visible or hidden Re-resolveStyle Paint Ask frames to paint <------- This is really bad since we since we haven't completed the reflow which sets the position and size of the frames. It causes garbage to displayed between page loads because the damaged rect is copied from the backbuffer but it has not been properly rendered into because its in the middle of reflow. CC'ing evaughan, GfxScrollbar guy.
I have a fix which prevents the setting of attributes during reflow from causing a synchronous paint.
Whiteboard: [PDT+] → [PDT+] Have fix in my tree.
Fixed in 2/9/2000 8:00am build.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
With the Feb 10 build (2000021008), I not reproducing the original problem described. Marking as verified fixed.
Status: RESOLVED → VERIFIED
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
You need to log in before you can comment on or make changes to this bug.