Closed
Bug 20150
Opened 25 years ago
Closed 25 years ago
Browsing area flashes garbage between page loads
Categories
(Core :: Layout, defect, P3)
Core
Layout
Tracking
()
VERIFIED
FIXED
M14
People
(Reporter: gerbilpower, Assigned: kmcclusk)
References
Details
(Whiteboard: [PDT+] Have fix in my tree.)
Attachments
(4 files)
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?
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M13
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.
Assignee | ||
Updated•25 years ago
|
Target Milestone: M13 → M15
Assignee | ||
Comment 4•25 years ago
|
||
Moving to M15
Comment 5•25 years ago
|
||
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.
Comment 6•25 years ago
|
||
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.
Comment 7•25 years ago
|
||
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).
Comment 9•25 years ago
|
||
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.
Comment 10•25 years ago
|
||
Adding myself to the CC list.
Comment 11•25 years ago
|
||
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
Comment 12•25 years ago
|
||
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...
Comment 13•25 years ago
|
||
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.
Comment 14•25 years ago
|
||
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.
Comment 15•25 years ago
|
||
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.
Comment 16•25 years ago
|
||
Reporter | ||
Comment 17•25 years ago
|
||
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.
Comment 18•25 years ago
|
||
Comment 19•25 years ago
|
||
Comment 20•25 years ago
|
||
*** Bug 25715 has been marked as a duplicate of this bug. ***
Comment 21•25 years ago
|
||
*** Bug 26001 has been marked as a duplicate of this bug. ***
Comment 22•25 years ago
|
||
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.
Comment 23•25 years ago
|
||
Comment 24•25 years ago
|
||
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.
Assignee | ||
Comment 25•25 years ago
|
||
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
Comment 26•25 years ago
|
||
I'm now seeing this on my Win98 HP Laptop as of 2/1 build Adding beta1 keyword
Keywords: beta1
Assignee | ||
Comment 28•25 years ago
|
||
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.
Assignee | ||
Comment 29•25 years ago
|
||
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.
Assignee | ||
Comment 30•25 years ago
|
||
Fixed in 2/9/2000 8:00am build.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 31•25 years ago
|
||
With the Feb 10 build (2000021008), I not reproducing the original problem described. Marking as verified fixed.
Status: RESOLVED → VERIFIED
Comment 32•22 years ago
|
||
Mass removing self from CC list.
Comment 33•22 years ago
|
||
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.
Description
•