They couldn't legally do it even if they wanted to, at least without explicit permission from the keepass developer. keepass is licensed under the GPL. Mozilla code is licensed under a more permissive license (once that gives you the choice of treating the code as being licensed under the GPL, LGPL, or MPL). As a result, using keepass in Mozilla code would be a license violation (e.g. it would amount to distributing keepass as LGPL if someone uses the Mozilla code under the LGPL).
The problem with this approach is that it violates the synchronous run-to-completion semantics web code assumes. In particular, shunting off cross-window function calls through the event loop would lead to races in web JS code, which is absolutely expecting everything it can see (including things it opens via window.open) to be running in a single thread.
Combined with the fact that in Firefox web and non-web JS are both around and that non-web JS can touch all objects in all open windows, threading things becomes a bit of a pain...
You seem to be assuming that all the money is being spent. The Mozilla financials (which are public) show that this is not the case. A significant portion is being saved.
Which is a good thing -- it means that if at some point in the future Google demands something that is not consistent with the Mozilla Foundation mission Mozilla can walk away from the arrangement and continue to operate off the savings while looking for another revenue stream.
> boohoo, then how does Opera, IE, and previous version of even Firefox do so much better?
They don't, if you look at the memory usage numbers... Over here (granted, on Linux) Opera 9 and Firefox are about comparable for memory used for page rendering.
Opera _is_ somewhat faster, though. "How" is a good question.;)
But my point was that rendering current web sites while using a small amount of RAM and doing it fast is NOT an easy problem to solve, which is what your original post was implying.
The main reason at this point is that making anything Unicode-like work on Win98 is pretty much impossible. So instead of continuing to try, all that code was ripped out and Win98 support was dropped.
You've never tried to "process and display html/images" (oh, and provide a scripting environment, and a DOM, and all the other bells and whistles people absolutely demand from web browsers), have you?
It'd be easy to use a lot less RAM and increase pageload speed a good bit -- drop support for most of the DOM and most of CSS.
Several things going on there, but the biggest issue is images. When a page is loaded, the images are decompressed (from PNG/JPEG/GIF/whatever) and stored in memory as 24-bit-color bitmaps (with 8 bits of alpha channel if it's a GIF or a PNG that actually uses alpha). So a 800px by 100px banner ends up being 800 * 100 * 24 == 1,920,000 bytes. The fast-back cache stores the DOM as it's rendered, with all images uncompressed, etc. This can add up quickly. There are proposals to drop the image and re-recode it as needed, or to have graphics system support for compressed images (e.g. allow storing a JPEG server-side on X and using the graphics hardware when it comes time to paint it), but they're not far along yet.
Well... If that's the attitude you want to take, all scientific statements are inaccurate. Every single one, when stated properly has error bars and qualifications.
Put another way, Newtonian mechanics is inaccurate. But it's accurate enough for modeling things like cars and bridges, and used for that all the time with great success. The simplifying assumptions it makes work well for those cases.
Special relativity is inaccurate. But it's accurate enough for modeling cars, bridges, light, and "large enough" chunks of matter moving far from any other chunk of matter. It's used for these purposes (though not so much for cars and bridges, see Newtonian mechanics above). The simplifying assumptions it makes work well for those cases.
Similarly, pretty much everything being said about climate, by everyone, is inaccurate. The only questions are what the error bars are and what simplifying assumptions are being made.
It's very common to not discuss the simplifying assumptions being made when describing a theory to a non-technical audience. That makes the theory being described "less accurate", because a prediction like "The temperature will go up 5 degrees in the next 50 years" is a lot more likely to disagree with experiment than a prediction like "If we assume that current usage trends of fossil fuels continue and we assume particular atmospheric models, we predict that the temperature will go up at least 1 degree in the next 50 years with a confidence of 95% and that the temperature will go up at least 5 degrees in the next 50 years with a confidence of 50%."
Google pays for the searches via the search bar. I'm not convinced they pay for the ones coming from the location bar. Last I checked, the two did different searches, and one of them didn't advertise itself as coming from Firefox.
> how well do electric cars hold their charge when temps are 0-20 degrees?
I wonder whether it would make sense for the battery to keep itself from getting too cold by operating a small heating coil. Some torpedo designs do this, and get significantly longer range as a result, but the operating parameters are very different there (don't need to warm the battery for very long).
> A mortgage should always be cheaper than renting: why would you possibly think your landlord's > mortgage was higher than your rent?
It's not, of course. But if the landlord bought the property before the recent bubble, his mortgage is lower than anything you'll be able to find yourself.
Actually, MIT does sort of have one. It's just called "Brain and Cognitive Sciences". See . Not exactly pure psychology, but then again you never made it clear why a psychology department is a prereq for a medical school...;)
CSS is meant to style documents. As a result, it leaves a _lot_ to be desired as a UI specification language. Basic things like vertical centering are pretty much impossible, because horizontal and vertical layout are very asymmetric in CSS -- widths are inputs to the algorithm and heights are the outputs. For a UI specification language, you want to treat widths and heights in a much more similar manner.
It's not a trivial problem to solve, because web pages assume a single-threaded execution model. therefore any two web pages that can access each other must run on the same thread. That's basically all web pages, given enablePrivilege.
And worse yet, the UI is effectively the same thing as a web page in Firefox (rendered by the same rendering engine, has a DOM, etc). So you get very similar constraints.
The initial design docs for Mozilla did call for one thread per toplevel window, but that somehow never happened, and doing it retroactively is a huge undertaking.:(
Actually, there are a few issues with Safari on OSX. For example, the only UI OSX has for setting your default browser is... in the Safari preferences. Before they started shipping Safari there was an item for this in System Preferences.
Combine this with the various software that Apple installs that uses WebKit to function, and while you can uninstall the Safari UI you can't really very well uninstall the actual renderer. Pretty similar to the way IE works on Windows, actually.
The problem with SVG is that the working group is more interested in giving cell-phone makers a Flash competitor standard than in actually creating a vector graphics standard. This is why SVG is getting things like network socket APIs while fundamental problems with the "vector graphics" part are ignored.
> Is there any reason it's not possible to allow web pages to download pre-compiled > JavaScript byte code as well?
Probably not, except it involves freezing the bytecode format. The XDR format is not guaranteed stable across releases -- its primary purpose is effectively for a compiled-stuff cache, with fallback on the original script if the cache XDR version doesn't match the running version.
> Why as a matter of fact, yes, somebody HAS profiled SpiderMonkey.
What you link to is not a profile, but a benchmark. Not the same thing at all.
And note that nowhere did I say that SpiderMonkey is a very fast programming language. It's not, of course. It's got its speed issues. Not having carefully read the exact source of the benchmark you quote, I can't tell you how much of the performance shown on that benchmark is due to innate slowness and how much is due to poorly-written code, but I suspect it's more of the former than the latter.
What I objected to was the claim by "Anonymous Coward" that "almost all" Mozilla performance problems are related to SpiderMonkey. Some are, most are not. Telling which is the case involves doing a profile (figuring out which parts of the code time is spent in). Just running a benchmark does NOT give you this information.
The current JavaScript engine in Gecko compiles the script to bytecode and then executes the bytecode... This is done during script parsing (not execution).
> Almost all the problems people have with excessive CPU use are related to the JS engine.
By "related to" do you mean "there's some JS involved somewhere, possibly calling native code where lots of time is spent"? Or you mean "I've profiled it, and the time is spent in the JS engine"?
If you _haven't_ profiled it, then you're basically making assumptions that might or might not be right (but probably aren't, given most of the profiles of "JS is slow" bugs that I've seen -- in almost all cases the problem is actually in the DOM or layout code).
Slashdot Mirror
They couldn't legally do it even if they wanted to, at least without explicit permission from the keepass developer. keepass is licensed under the GPL. Mozilla code is licensed under a more permissive license (once that gives you the choice of treating the code as being licensed under the GPL, LGPL, or MPL). As a result, using keepass in Mozilla code would be a license violation (e.g. it would amount to distributing keepass as LGPL if someone uses the Mozilla code under the LGPL).
;)
Gotta love licenses.
The problem with this approach is that it violates the synchronous run-to-completion semantics web code assumes. In particular, shunting off cross-window function calls through the event loop would lead to races in web JS code, which is absolutely expecting everything it can see (including things it opens via window.open) to be running in a single thread.
Combined with the fact that in Firefox web and non-web JS are both around and that non-web JS can touch all objects in all open windows, threading things becomes a bit of a pain...
> $50 million is a lot of money to spread around
You seem to be assuming that all the money is being spent. The Mozilla financials (which are public) show that this is not the case. A significant portion is being saved.
Which is a good thing -- it means that if at some point in the future Google demands something that is not consistent with the Mozilla Foundation mission Mozilla can walk away from the arrangement and continue to operate off the savings while looking for another revenue stream.
What's the hit on download size from using MSLU?
;)
And it's not the only reason; e.g. lacking cairo support on Win9x is a problem too. The Unicode issue is just the least likely to go away.
Combined with the market share of Win9x (or lack thereof)...
> boohoo, then how does Opera, IE, and previous version of even Firefox do so much better?
;)
They don't, if you look at the memory usage numbers... Over here (granted, on Linux) Opera 9 and Firefox are about comparable for memory used for page rendering.
Opera _is_ somewhat faster, though. "How" is a good question.
But my point was that rendering current web sites while using a small amount of RAM and doing it fast is NOT an easy problem to solve, which is what your original post was implying.
The main reason at this point is that making anything Unicode-like work on Win98 is pretty much impossible. So instead of continuing to try, all that code was ripped out and Win98 support was dropped.
You've never tried to "process and display html/images" (oh, and provide a scripting environment, and a DOM, and all the other bells and whistles people absolutely demand from web browsers), have you?
It'd be easy to use a lot less RAM and increase pageload speed a good bit -- drop support for most of the DOM and most of CSS.
Several things going on there, but the biggest issue is images. When a page is loaded, the images are decompressed (from PNG/JPEG/GIF/whatever) and stored in memory as 24-bit-color bitmaps (with 8 bits of alpha channel if it's a GIF or a PNG that actually uses alpha). So a 800px by 100px banner ends up being 800 * 100 * 24 == 1,920,000 bytes. The fast-back cache stores the DOM as it's rendered, with all images uncompressed, etc. This can add up quickly. There are proposals to drop the image and re-recode it as needed, or to have graphics system support for compressed images (e.g. allow storing a JPEG server-side on X and using the graphics hardware when it comes time to paint it), but they're not far along yet.
> What I'm saying is Firefox should stick to one graphic toolkit on every platform. Right now
> that is GTK+
GTK+ is only used on Linux. On Windows and Mac the native widget sets are used for UI rendering as much as possible...
> What? It is either accurate or it is not
Well... If that's the attitude you want to take, all scientific statements are inaccurate. Every single one, when stated properly has error bars and qualifications.
Put another way, Newtonian mechanics is inaccurate. But it's accurate enough for modeling things like cars and bridges, and used for that all the time with great success. The simplifying assumptions it makes work well for those cases.
Special relativity is inaccurate. But it's accurate enough for modeling cars, bridges, light, and "large enough" chunks of matter moving far from any other chunk of matter. It's used for these purposes (though not so much for cars and bridges, see Newtonian mechanics above). The simplifying assumptions it makes work well for those cases.
Similarly, pretty much everything being said about climate, by everyone, is inaccurate. The only questions are what the error bars are and what simplifying assumptions are being made.
It's very common to not discuss the simplifying assumptions being made when describing a theory to a non-technical audience. That makes the theory being described "less accurate", because a prediction like "The temperature will go up 5 degrees in the next 50 years" is a lot more likely to disagree with experiment than a prediction like "If we assume that current usage trends of fossil fuels continue and we assume particular atmospheric models, we predict that the temperature will go up at least 1 degree in the next 50 years with a confidence of 95% and that the temperature will go up at least 5 degrees in the next 50 years with a confidence of 50%."
Google pays for the searches via the search bar. I'm not convinced they pay for the ones coming from the location bar. Last I checked, the two did different searches, and one of them didn't advertise itself as coming from Firefox.
> how well do electric cars hold their charge when temps are 0-20 degrees?
I wonder whether it would make sense for the battery to keep itself from getting too cold by operating a small heating coil. Some torpedo designs do this, and get significantly longer range as a result, but the operating parameters are very different there (don't need to warm the battery for very long).
> A mortgage should always be cheaper than renting: why would you possibly think your landlord's
> mortgage was higher than your rent?
It's not, of course. But if the landlord bought the property before the recent bubble, his mortgage is lower than anything you'll be able to find yourself.
> You do not even have a psychology department.
;)
Actually, MIT does sort of have one. It's just called "Brain and Cognitive Sciences". See . Not exactly pure psychology, but then again you never made it clear why a psychology department is a prereq for a medical school...
Designers are designing UIs.
CSS is meant to style documents. As a result, it leaves a _lot_ to be desired as a UI specification language. Basic things like vertical centering are pretty much impossible, because horizontal and vertical layout are very asymmetric in CSS -- widths are inputs to the algorithm and heights are the outputs. For a UI specification language, you want to treat widths and heights in a much more similar manner.
For what it's worth, the plan is for Firefox 3 to support inline-block.
It's not.
:(
It's not a trivial problem to solve, because web pages assume a single-threaded execution model. therefore any two web pages that can access each other must run on the same thread. That's basically all web pages, given enablePrivilege.
And worse yet, the UI is effectively the same thing as a web page in Firefox (rendered by the same rendering engine, has a DOM, etc). So you get very similar constraints.
The initial design docs for Mozilla did call for one thread per toplevel window, but that somehow never happened, and doing it retroactively is a huge undertaking.
Actually, there are a few issues with Safari on OSX. For example, the only UI OSX has for setting your default browser is ... in the Safari preferences. Before they started shipping Safari there was an item for this in System Preferences.
Combine this with the various software that Apple installs that uses WebKit to function, and while you can uninstall the Safari UI you can't really very well uninstall the actual renderer. Pretty similar to the way IE works on Windows, actually.
> And for those who cite that SVG is "bloated" because it's XML, maybe you haven't heard of > something called "compression"...
Compression doesn't help with the bloat caused by having to maintain a DOM.
Even if you take the SVG Tiny route and not have a DOM, you have to _parse_ said XML. There are libraries for this, but efficient it is not.
The problem with SVG is that the working group is more interested in giving cell-phone makers a Flash competitor standard than in actually creating a vector graphics standard. This is why SVG is getting things like network socket APIs while fundamental problems with the "vector graphics" part are ignored.
> Is there any reason it's not possible to allow web pages to download pre-compiled
> JavaScript byte code as well?
Probably not, except it involves freezing the bytecode format. The XDR format is not guaranteed stable across releases -- its primary purpose is effectively for a compiled-stuff cache, with fallback on the original script if the cache XDR version doesn't match the running version.
> An important feature currently missing from Firefox that I'm looking forward to is a way
x drapi.h#45 for the API.
> to load pre-compiled binary bytecode into Firefox
Actually, that feature exists and is used in Firefox at startup. See http://lxr.mozilla.org/seamonkey/source/js/src/js
Now you can't do it from inside the JavaScript language. But any consumer of the C JSAPI can do this.
> Why as a matter of fact, yes, somebody HAS profiled SpiderMonkey.
What you link to is not a profile, but a benchmark. Not the same thing at all.
And note that nowhere did I say that SpiderMonkey is a very fast programming language. It's not, of course. It's got its speed issues. Not having carefully read the exact source of the benchmark you quote, I can't tell you how much of the performance shown on that benchmark is due to innate slowness and how much is due to poorly-written code, but I suspect it's more of the former than the latter.
What I objected to was the claim by "Anonymous Coward" that "almost all" Mozilla performance problems are related to SpiderMonkey. Some are, most are not. Telling which is the case involves doing a profile (figuring out which parts of the code time is spent in). Just running a benchmark does NOT give you this information.
The current JavaScript engine in Gecko compiles the script to bytecode and then executes the bytecode... This is done during script parsing (not execution).
> Almost all the problems people have with excessive CPU use are related to the JS engine.
By "related to" do you mean "there's some JS involved somewhere, possibly calling native code where lots of time is spent"? Or you mean "I've profiled it, and the time is spent in the JS engine"?
If you _haven't_ profiled it, then you're basically making assumptions that might or might not be right (but probably aren't, given most of the profiles of "JS is slow" bugs that I've seen -- in almost all cases the problem is actually in the DOM or layout code).