125260 - eliminate paint suppression delay for first page?

Status: RESOLVED DUPLICATE of bug 157144

(Core :: Layout, defect, P2)

Description

[Ken]

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())

Comment 1

[Kevin McCluskey (gone)]

Reassigning to paint suppression author: Hyatt. 

Comment 2

[Ken]

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.

Comment 3

[Ken]

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>

Comment 4

[Ken]

ah, bugzilla.... here is Hyatt's post, since the link is busted:

Message 1 in thread 
From: David Hyatt ([e-mail])
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
([e-mail])

Comment 5

[Judson Valeski]

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

[David Hyatt]

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

[David Hyatt]

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

[Dave Barrowman]

What is the next step here?  Is there any chance of this getting worked on in
the near term?

Comment 9

[Juan José Mata]

Can you help/comment here, Simon?

Comment 10

[Simon Fraser [no longer active]]

Kevin should be able to help here.

Comment 11

[Jo Hermans]

   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 ?)

Comment 12

[Kevin McCluskey (gone)]

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?

Comment 13

[Ken]

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."

Comment 14

[Kevin McCluskey (gone)]

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 ***