61942 - RFE: Mozilla should use one thread pre window

Status: VERIFIED INVALID

(SeaMonkey :: UI Design, enhancement, P3)

Description

[Roland Mainz]

RFE: Mozilla shoould use one thread per "main window" (browser window/messenger
window etc.).

Currently Mozilla behaves very "sluggish" (or pauses/stops responding to user
actions) when opening a new window, loading new emails/news and so on...
One "solution" to this issue would be to handle each "main window" in a
seperate, independend thread; new windows are handled by new threads, initially
running at a lower priority than the other threads until it reaches a cretain
mark (for example that the window loaded it's initial context completely and
becomes visible).

Comment 1

[timeless]

This is not an all/all bug. BeOS does things differently, please file per 
platform.

In fact the summary is innaccurate because you want each window to get a thread 
for its gui, but there may be additional threads for chrome functions (eg 
javascript), and netwerk, ...

Please include build id and some measure of performance. [what you get now, 
what something else gets now, and what you expect from mozilla in the future]

Comment 2

[Roland Mainz]

Added example URL and added OS (better would be: Linux/Solaris/WinNT).
Try to load that page on a slower machine (~200MHz x86 or SPARC).
Mozilla starts to load that page and images but does not respond to any user
interaction (click on chrome button ot slider move) or attempt to resize the
window.
Adding more threads may be a solution. Using thread priorities may be another
(like that chrome get's higher priority than "(HTML) content" windows...).

Comment 3

[Asa Dotzler [:asa]]

updating component.

Comment 4

[timeless]

*** Bug 63004 has been marked as a duplicate of this bug. ***

Comment 5

[Duncan Findlay]

*** Bug 63004 has been marked as a duplicate of this bug. ***

Comment 6

[Paul Chen]

nav triage team:

Not sure more threads is the solution. Mozilla/NS6 is a big app, lots of things 
could be factors (e.g. eval xul files for chrome). Also, allocating lots of 
memory takes a lot of time. At any rate, won't be addressing this for beta1. 
Marking nsbeta1-

Comment 7

[Roland Mainz]

More threads are not a solution, but more threads _and_ chossing "good"
scheduler priorities for the threads would be one.

For example: A thread which decodes a "progressive" GIF/JPEG/PNG image may get a
"lower" priority after the first image has been displayed (e.g. user sees
something).

Other usefull places would be the sidebar, both loading and handling may be done
in a thread with a lower priority than the right hand "main content"...

Comment 8

[Chris McAfee]

not sure how architectually correct this proposal is,
over to brendan for a look.

Comment 9

[Roland Mainz]

Technically it is the request to avoid the issue that one busy Mozilla window
blocks _other_ busy Mozilla windows. If one window is loading/rendering other
windows do not respond to user input until the other window has finished it's
work.

Comment 10

[Brendan Eich [:brendan]]

Gecko is not a multi-threaded or even thread-able (threadsafe) layout engine. 
It might be one day.  Until then, we have to ensure responsiveness by ensuring
that all control flows from the event loop return to that loop soon enough
(ideally, within a tenth of a second).  For some inputs, I'm sure Gecko is
running too long before returning to the event loop.

This bug should not describve a solution to a problem, it should describe the
problem that threads might solve (if we had time to multi-thread Gecko and the
rest ofthe Mozilla code that's not threadsafe; pretty much everything except
NSPR, JS, Necko, and a few other modules).

There is a bug asking for someone to measure event-to-event latency.  Another
bug (or bugs?) talk about interruptable layout.  Perhaps this bug could be
dependent on that one?  Or marked as a DUPLICATE, or as REMIND even.

As written, the bug is a premature conclusion that doesn't help us in the near
term.  I'm reassigning to the reporter for better disposition.  The best thing
would be to instrument the event loop and report on the event-to-event time
distribution given top100, worst-case, and other interesting inputs.

/be

Comment 11

[Roland Mainz]

Marking as "invalid" to get this rid of my bug list for now... some things are
better now... some not (for example... printing still blocks the browser...
which can take 10mins or more in some cases...)... ;-(

Comment 12

[sairuh (rarely reading bugmail)]

mass verification of Invalid bugs: to find all bugspam pertaining to this,
set your search string to "MagaritaLuisaChascarilloAvoidsInvalidBugs".

if you think this particular bug is *still* an open issue, please make sure of
the following before reopening:

a. where relevant, do check that it's actually still a problem with ***recent
trunk builds*** on the all appropriate platform[s]

b. provide clear, compelling reasons why this bug should be considered a valid one.