Closed Bug 5849 Opened 27 years ago Closed 26 years ago

[Content sink] frames load strangely in apprunner

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect, P2)

Product:
Core
Component:
Layout: Images, Video, and HTML Frames
Platform:
x86
Windows 95
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: dbaron, Assigned: nisheeth_mozilla)

References

(
URL
)

Details

(Keywords: perf, Whiteboard: [Perf])

There are problems with frame loading in apprunner, because the previously displayed page is shown in each frame before the page in that frame loads. I think this is the "keep displaying old page until new page loads" gone one step too far.
Assignee: don → karnaze
Component: Apprunner → HTMLFrames
Assignee: karnaze → hyatt
I've seen this behavior in Apprunner but not in Viewer. Reassigning to Hyatt.
Status: NEW → ASSIGNED
I'll look into this, but I do feel compelled to point out that just because you see this in apprunner and not in viewer, that doesn't mean that it's a XUL or apprunner bug. Apprunner is nesting framesets inside an iframe, which is something that a web page designer might do entirely in viewer. It may be the case that many of these problems are related to this nesting and therefore aren't apprunner-specific. I'll look into it and see if I can reproduce it in viewer.
Similar problems (actually somewhat worse) are visible on http://www.fas.harvard.edu/~dbaron/sat/frames.html.en in the same situations.
yep, David's page is a perfect example of how the layout is a bit "off" on the initial rendering -- good job David.
QA Contact: 3853 → 3849
Updating QA Contact
Target Milestone: M9
What I described in bug 6403 may be useful in diagnosing this. In that problem, it seemed that the display in the sidebar frame was one refresh behind the main frame.
The problem persists after the page is loaded in the lower left frame of http://www.eage.nl/student/
Another thing to note is that all this stuff that is happening is slow - this could be a performance problem in apprunner. Note also that it's not platform- specific (or at least it happens on Win95 and Linux). I'm also seeing stuff similar to bug 6403 in the source tarball from June 2. Raising priority to P2.
Whiteboard: [Perf]
Target Milestone: M9 → M10
Blocks: 8691
Assignee: hyatt → nisheeth
Status: ASSIGNED → NEW
Tested this extensively, and other than the fact that viewer is doing fewer repaints (because of numerous reflow bugs), there is no difference between viewer and apprunner. This problem primarily persists because of Gecko's inability to begin displaying a document quickly and incrementally. I believe that when more batching is done at the HTML content sink level (and that when repaint problems caused by extra apprunner reflows, etc. etc. get resolved) that this problem will go away. Reassigning to nisheeth who works with content sinks. I believe getting something into the frame as fast as possible is the key to solving this bug, and that involves getting content from the newly loading document into the frame as fast as possible.
Did i just repeat myself? :) It's 1:31. Sigh. I should sleep.
One note about the strangeness - try *resizing* http://www.eage.nl/student/ in apprunner. It takes my apprunner about 5 seconds (Linux, PII/233), during which time I see pieces of the apprunner chrome. I get the feeling that each frame's content is being painted in every frame, or something like that... and since apprunner has more frames, it takes a lot longer (O(n^2)??). In viewer, I see pieces of other frames, but there's no chrome to mess it up, and it's quite a bit faster.
Status: NEW → ASSIGNED
Accepting bug and ccing Peter as he is going to work on making the content sink issue more incremental layout requests than it does now.
Summary: frames load strangely in apprunner → [Content sink] frames load strangely in apprunner
*** Bug 4947 has been marked as a duplicate of this bug. ***
*** Bug 7200 has been marked as a duplicate of this bug. ***
Just verifying that this is still occurring with the latest NECKO builds on 08/05.
Moving content sink code factoring related bugs to M12.
The content sink code factoring has been postponed to post beta. Moving related bugs out to M15.
QA Contact: beppe → petersen
The content sink is much more incremental now, thanks to Vidur's changes. I've tested the pages mentioned on this page and perceived performance is much better. David, please see how these pages are loading in the current builds and give your vote regarding whether this bug should be closed. Thanks.
Perhaps I'll have time to pull and build this weekend and test this with paint flashing turned on. (My current debug build is over a week old.) (Hmmm. I wonder if there's any chance debug builds could be posted on mozilla.org occasionally...) I suspect there may be some painting bugs with frames - such as causing the entire document to repaint when only one needs a repaint, but I'd really need to try it with paint flashing to be sure.
I think many of the problems here are with painting. There are way to many repaints involved with frames. I think a good case to attack is the case of resizing a page with frames, since there are no issues of rebuilding content and everything can be considered a painting bug. Once the painting is fixed, it will, i think, be clearer what else is going on. When I resize (by toggling maximize vs. restore, which only causes one resize) the page http://www.fas.harvard.edu/~dbaron/sat/frames , which has 3 frames, I see the following repaints using paint flashing: These are repaints occurring at the new size but the *old* position: * each of three frames repaints 6 times (order is always TL, BL, then R). These seem to vary by the width of a scrollbar in and out. * each of 3 - 6 times * each of 3 - 2 times ... the rest of this list is uncertain, because it's hard for me to follow... * 3(?) repaints of whole document frame * each of 3 - 1 time * entire document repaint * each of 3 - 1 time * entire document repaint * 2 left frames repaint * some chrome repaints Then the frames move to the correct position, and: * each frame repaints once * all of chrome repaints * a bunch of areas where the frame that was at that spot has changed repaint, and a few other things. (maybe 15-20 repaints total here) Some of this could be worse on Linux than other platforms, but there is no way you need this many repaints (I think it's about 75-100 total repaints for a single resize). This was done on a debug build from a tree pulled 1999-10-29 09:30PDT.
See also bug 7289: "Layout engine does not paint when there is no content".
David, please check and see if the latest improvements to rendering have made things better. If they have, we can close out this bug. Thanks.
Keywords: perf
Bulk add of "perf" to new keyword field. This will replace the [PERF] we were using in the Status Summary field.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → WORKSFORME
Resizing http://www.fas.harvard.edu/~dbaron/sat/frames looked reasonable on windows. I'm marking this bug worksforme so that it can be tested on other platforms.
Loading the URL in the URL field is still quite slow, IMO.
Keywords: verifyme
On 3/10-3/14 builds we can't verify on Win95 or Linux. We are crashing on http://www.nic.fi/~tapio1/Opera/index.html filed bug 31903
I'm not able to reproduce the orignal problem with the April 20 build under Mac OS 9, Windows 98, and Linux.
Status: RESOLVED → VERIFIED
Keywords: verifyme
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.