Closed
Bug 125260
Opened 23 years ago
Closed 22 years ago
eliminate paint suppression delay for first page?
Categories
(Core :: Layout, defect, P2)
Tracking
()
RESOLVED
DUPLICATE
of bug 157144
mozilla1.3beta
People
(Reporter: runyonkj, Assigned: kmcclusk)
References
Details
(Keywords: perf, topembed+, Whiteboard: [whitebox])
Working on an embedded client. I understand there is a 2 second paint suppression delay for each page load (is that the case?) If this is the case, can we remove the delay in the case where there is no current document viewer or the current docview is about:blank? (In the embedding case, we are creating a native window (win32), followed eventually with the call to nsIWebBrowserNavigation::LoadURI())
Assignee | ||
Comment 1•23 years ago
|
||
Reassigning to paint suppression author: Hyatt.
Assignee: attinasi → hyatt
Updated•23 years ago
|
QA Contact: petersen → moied
Hyatt-can you confirm my description of what's happening here? And whether we can eliminate the delay for new windows (where there is no DocView or the content is about:blank -- important for the embedding case)? adding Rick Potts and Chris Saari to the cc list.
Related discussion (post by Hyatt) found on google <a href="http://groups.google.com/groups? hl=en&newwindow=1&safe=active&threadm=3BF2C5E8.1080205% 40netscape.com&rnum=1&prev=/groups%3Fq%3Dpaint%2Bsuppression%26hl%3Den% 26newwindow%3D1%26safe%3Dactive%26selm%3D3BF2C5E8.1080205%2540netscape.com% 26rnum%3D1">paint suppression</a>
ah, bugzilla.... here is Hyatt's post, since the link is busted: Message 1 in thread From: David Hyatt (hyatt@netscape.com) Subject: Paint Suppression Perf Comparison Newsgroups: netscape.public.mozilla.performance View this article only Date: 2001-11-14 11:25:27 PST I'm pretty sure that my changes to how messages are prioritized has caused some interesting issues with paint suppression on Win32 only. I ran the performance tests with the paint suppression delay set to 0 and at the default (1200 ms). Perf Results at 0 ms - 547ms Perf Results at 1200 ms - 541ms In other words, no difference, and that just isn't right. I noticed that certain pages seem to be staying suppressed for way too long, and this suppression seems to be independent of the timer delay value. In particular, the DOM Level 2 Core spec page and the voodoo extreme page both stayed suppressed all the way until they were done, even when the time delay was set to 0! Dave (hyatt@netscape.com)
Comment 5•23 years ago
|
||
this should be configurable via prefs. different apps will want to tune this based on user base (slow modems, broadband, disk only, etc).
Comment 6•23 years ago
|
||
The changes I made to event prioritization were SeaMonkey only and have no effect on embedding. It is incorrect to finger paint suppression here. Embedding clients on Win32 have *always* had a problem displaying Web pages incrementally, and that problem is independent of paint suppression. Also, paint suppression is configurable via a pref already, but as I said in that message, the problem with pages not displaying is independent of paint suppression. You can turn paint suppression off completely, and you'll still have a delay before pages show up).
Comment 7•23 years ago
|
||
There are a couple of routes to making page display more incremental. The first is to fix layout to be more interruptible, or to duplicate the original event prioritization patches that went into SeaMonkey (and that I subsequently backed out later) in your own app's message loop. I favor the first approach, i.e., make Gecko really work. :)
Comment 8•22 years ago
|
||
What is the next step here? Is there any chance of this getting worked on in the near term?
Updated•22 years ago
|
Whiteboard: [whitebox]
Updated•22 years ago
|
Comment 11•22 years ago
|
||
See bug 180241 : since dec 26th, we're experimenting with a default delay of 250 msec, instead of 1200. The final value might change though (500 ?)
Assignee | ||
Comment 12•22 years ago
|
||
The problem mentioned in comment 4 was fixed by the checkin for bug 157144. Looking at the painting suppression code it should unsuppress when either 1.2 seconds have passed or the document has completed loading. For about:blank it should complete the load and unsuppress the painting without waiting 1.2 seconds. bug 180241 discusses changing the 1.2 seconds to 250ms but that should not be an issue for this bug since painting for about:blank should be unsuppressed immediately. Ken: Are you seeing that painting is being suppressed when about:blank is loaded?
Target Milestone: --- → mozilla1.3beta
Reporter | ||
Comment 13•22 years ago
|
||
The original bug was written based on a discussion with David Hyatt. However, he has supplied more info in comments 6 and 7 above: "Embedding clients on Win32 have *always* had a problem displaying Web pages incrementally, and that problem is independent of paint suppression."
Assignee | ||
Comment 14•22 years ago
|
||
Ok, this a dup of bug 157144 which has been fixed. The problem was the mechanism that was used for dispatching plevents on WIN32 was starving paint events. In the past this was partially solved by reording msg processing in the main event loop to process WM_PAINT messages ahead of the posted WM_APP messages. However, this didn't help embedded applications because they didn't or couldn't contain this sort of reording logic. This only partially solved the problem for Mozilla because when the user moved a toplevel window the app would freeze because windows goes into a separate event loop for processing events which does not contain the logic to process WM_PAINT messages ahead of other messages and all painting would be starved until the page completely loaded. The fix was to change the notification of plevents to use a WM_TIMER instead of a WM_APP event if the painting was being starved. The special WM_PAINT processing is no longer needed, so embedded apps do not need to make any modification to their event processing loop to get good incremental display. As a result, MFCEmbed is just as incremental and interactive as Mozilla during a long page load. *** This bug has been marked as a duplicate of 157144 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•