> The roadmap doesn't say much about the work > planned for 1.1 and eventually 2.0
Well, for example there is this "rewrite all of reflow" patch that waterson, jkeiser, and shaver are working on...:)
There's also a whole slew of fixes to the helper app subsystem that should be landing in the next two to three months (Bill Law has a big XP patch and I'll be rewriting a lot of the Linux code in the wake of that to make it deal better with mailcap files).
I'm sure there are other things I just don't know about.
Did you file a bug? Which version were you trying? Testcase?:)
I can name at least 3 bugs that could have fixed your problem that got fixed in the last 2 months. If you actually gave a specific description of the problem (what's a "field" here?) I would likely be able to point you to the exact bug on it....
> Does Mozilla 'do the right thing' with a > read-only NFS mounted directoy yet?
No, unfortunately.
> How does one install Netscape plugins into > mozilla on unix and windows?
Just drop the shared libs in the plugins/ dir in the Mozilla install directory.
> Will there *EVER* be a release of mozilla or > netscape 6.X that runs on glibc-2.0 systems?
In short, "no". glibc-2.0 has a threading bug that crashes Mozilla consistently. There were some extended attempts to work around it in the app but once it became clear that fixing this on the app end would essentially involve forgoing the use of libc threads while glibc-2.1 had the bug fixed, the decision was made to just no support glibc-2.0.
It'll build for OpenBSD when someone ports the XPC assembly code that XPConnect uses to OpenBSD. This would benefit greatly from the help of someone familiar with the OpenBSD kernel...
Agreed. The core netwerk developers seem to feel that this is not a good enough reason to incur the extra memory overhead... Again, the source _is_ saved (in cache) so all that needs to happen is that it be retrieved. The API to do that is being (slowly) put in place.
> I need the source of WHAT THE BROWSER IS SHOWING
> AT THIS MOMENT IN TIME
Which, with client-side scripting involved, has nothing to do with the source that was served from the website (consider a page that dynamically creates and appends some elements.
The fact of the matter is, there is no good reason to keep the source once it has been parsed, so Mozilla do it. The only place the source stays is in the cache. Thus the problem becomes one of extracting the correct cache entry.
And Mozilla always prints exactly what you see; it prints based on the DOM, not on the source.
15% is about as much as typical _good_ algorithmic speedups have been giving. A typical algorithmic speedup will make some class of cases much faster, make some class of cases a bit slower, and not affect most cases. It usually averages out to a few percent improvement overall.
One problem with this reasoning. The common case is poorly written code on the web. The common case is the one that has broken syntax (something compilers usually error on, not correct). The common case is the one that has 10 levels of nested tables (fairly common on major commercial sites).
The fact of the matter is, a typical webpage has more "boxes" involved than a typical UI (where a "box" is something that has to be sized and then placed).
Also, if you look carefully at the capabilities provided by the toolkits you mention you will see that they are not nearly as flexible as CSS. Trasparent backgrounds? Not really. Translucent boxes? No. Decent bidi? Not in gtk as of last time I checked (not sure about QT).
There is a separate issue. When you write a toolkit you can pick a box model that will allow you to make a fast resizable engine. With web content there is an existing box model (CSS) and it's not exactly optimized for performance....
I agree that this is not rocket science. It's completely orthogonal and in some ways much harder (I can do rocket science; I can't write a decent HTML _parser_ much less layout engine).
Unfortunately, a lot of the work Mozilla does _is_ tight number-crunching loops of various sorts. What do you think layout is? It's a lot of recursive number-crunching. So yes, the compiler is making a large difference here. Going from -O to -O2 with gcc (the milestones use -O) leads to a 15% speed increase pretty much across the board for all operations (page loading, new window, etc)
Re:why is mozilla engine so slow?
on
Netscape 6.2
·
· Score: 2
This argument would be more cogent if it were not for the fact that IE6 also draws all its widgets in web pages "by hand". The simple reason for this is that the native widget set simply does not support the functionality required of web page form widgets by CSS.
> Hit Bridge.com in Netscape 4.7x and then hit it > in any 6.x netscape... What happened?
What happened is that bridge.com decided that NS 6 is NS4 and gave it proprietary javascript that is only supported by NS4 and not any other browser on the planet. And NS6 naturally refused to deal with it.
Alternately, what happened is a site designer who has not yet had a chance to make the site work per the DOM spec that's after all only been in existence and been supported by IE for 2 years now.
Slashdot Mirror
> The roadmap doesn't say much about the work
:)
> planned for 1.1 and eventually 2.0
Well, for example there is this "rewrite all of reflow" patch that waterson, jkeiser, and shaver are working on...
There's also a whole slew of fixes to the helper app subsystem that should be landing in the next two to three months (Bill Law has a big XP patch and I'll be rewriting a lot of the Linux code in the wake of that to make it deal better with mailcap files).
I'm sure there are other things I just don't know about.
> I mean, when was the last time you saw a binary created by GCC for Windows
:)
About a year ago, the last time I built something on Windows...
SUNWspro builds Mozilla fine. The resulting builds are about 30% faster across the board at everything than gcc builds on Solaris are.
> But no one wants to port it to my OS. I won't do it because I am a parasite.
:)
There we have the crux of the matter.
> I'm wondering when they are going to put spell checking in.
:)
As soon as someone writes it.
Did you file a bug? Which version were you trying? Testcase? :)
I can name at least 3 bugs that could have fixed your problem that got fixed in the last 2 months. If you actually gave a specific description of the problem (what's a "field" here?) I would likely be able to point you to the exact bug on it....
Or even "FTP sucks because it's insecure" or "HTML sucks because it does not enforce well-formedness".
And all these statements would be true... Protocols are not necessarily perfect.
> Why is Moz so much faster under Windows than
> under Linux ?
A few reasons:
1) More Windows developers means more optimizations in platform-specific code on windows
2) MSVC is a better C++ compiler than gcc and produces smaller and faster code
And completely wrong. And encouraging inaccessible web design. Hence will not be done.
No problem. :)
> Does Mozilla 'do the right thing' with a
> read-only NFS mounted directoy yet?
No, unfortunately.
> How does one install Netscape plugins into
> mozilla on unix and windows?
Just drop the shared libs in the plugins/ dir in the Mozilla install directory.
> Will there *EVER* be a release of mozilla or
> netscape 6.X that runs on glibc-2.0 systems?
In short, "no". glibc-2.0 has a threading bug that crashes Mozilla consistently. There were some extended attempts to work around it in the app but once it became clear that fixing this on the app end would essentially involve forgoing the use of libc threads while glibc-2.1 had the bug fixed, the decision was made to just no support glibc-2.0.
user_pref("middlemouse.openNewWindow", false);
should help most of your problems.
> For instance you can't use the 3rd mouse button on
> OS X to paste.
This is because OSX has no concept of a 3rd mouse button and never passes the click event on to applications...
You can't do a custom build without it easily. There is no clean way to disable it.
It'll build for OpenBSD when someone ports the XPC assembly code that XPConnect uses to OpenBSD. This would benefit greatly from the help of someone familiar with the OpenBSD kernel...
Um... which mozilla is this? Mozilla's support for Arabic is not complete (I know shaping is being worked on) but it's fairly decent...
Agreed. The core netwerk developers seem to feel that this is not a good enough reason to incur the extra memory overhead... Again, the source _is_ saved (in cache) so all that needs to happen is that it be retrieved. The API to do that is being (slowly) put in place.
Sure. That would be fairly easy to do. Or you could fire up Document Inspector (which is a lot more useful than raw source).
> I need the source of WHAT THE BROWSER IS SHOWING
> AT THIS MOMENT IN TIME
Which, with client-side scripting involved, has nothing to do with the source that was served from the website (consider a page that dynamically creates and appends some elements.
The fact of the matter is, there is no good reason to keep the source once it has been parsed, so Mozilla do it. The only place the source stays is in the cache. Thus the problem becomes one of extracting the correct cache entry.
And Mozilla always prints exactly what you see; it prints based on the DOM, not on the source.
15% is about as much as typical _good_ algorithmic speedups have been giving. A typical algorithmic speedup will make some class of cases much faster, make some class of cases a bit slower, and not affect most cases. It usually averages out to a few percent improvement overall.
One problem with this reasoning. The common case is poorly written code on the web. The common case is the one that has broken syntax (something compilers usually error on, not correct). The common case is the one that has 10 levels of nested tables (fairly common on major commercial sites).
The fact of the matter is, a typical webpage has more "boxes" involved than a typical UI (where a "box" is something that has to be sized and then placed).
Also, if you look carefully at the capabilities provided by the toolkits you mention you will see that they are not nearly as flexible as CSS. Trasparent backgrounds? Not really. Translucent boxes? No. Decent bidi? Not in gtk as of last time I checked (not sure about QT).
There is a separate issue. When you write a toolkit you can pick a box model that will allow you to make a fast resizable engine. With web content there is an existing box model (CSS) and it's not exactly optimized for performance....
I agree that this is not rocket science. It's completely orthogonal and in some ways much harder (I can do rocket science; I can't write a decent HTML _parser_ much less layout engine).
Unfortunately, a lot of the work Mozilla does _is_ tight number-crunching loops of various sorts. What do you think layout is? It's a lot of recursive number-crunching. So yes, the compiler is making a large difference here. Going from -O to -O2 with gcc (the milestones use -O) leads to a 15% speed increase pretty much across the board for all operations (page loading, new window, etc)
This argument would be more cogent if it were not for the fact that IE6 also draws all its widgets in web pages "by hand". The simple reason for this is that the native widget set simply does not support the functionality required of web page form widgets by CSS.
> Hit Bridge.com in Netscape 4.7x and then hit it > in any 6.x netscape... What happened?
What happened is that bridge.com decided that NS 6 is NS4 and gave it proprietary javascript that is only supported by NS4 and not any other browser on the planet. And NS6 naturally refused to deal with it.
Alternately, what happened is a site designer who has not yet had a chance to make the site work per the DOM spec that's after all only been in existence and been supported by IE for 2 years now.
ctrl-pageup and ctrl-pagedown