[quote]Originally posted by eVo:
<strong>What if the OmniGroup just abandoned OmniWeb's proprietary engine and used Gecko (Mozilla's engine)? It's faster, more compliant with websites...</strong><hr></blockquote>Drop my MacNN and ask that question.
You will get REAMED. <img src="graemlins/lol.gif" border="0" alt="[Laughing]" />
Rick and Ken and Greg have explained this issue in great depth several times before. I'll find one of the threads and give you a link...
edit: okay, here's a good one:
<a href="
http://forums.macnn.com/cgi-bin/ultimatebb.cgi?ubb=get_topic;f=37;t=003527" target="_blank">
http://forums.macnn.com/cgi-bin/ultimatebb.cgi?ubb=get_topic;f=37;t=003527</a>
[quote]Originally posted by Rickster:
Why not just throw in the towel and make OmniWeb just another UI for Mozilla? Maybe it's pride, as Fotek suggests. Or maybe we think we can do better. I'll try explaining again why that might we worth our effort...
In the spirit of those Mac OS X architecture diagrams we've all seen a million times by now, here's a quick picture of what goes on in a web browser:
None of these parts of a web browser's "engine" is trivial: we (and the makers of other browsers) have invested much engineering effort into each.
Now, the state of affairs in OmniWeb 1.x-4.x is that the layout & display component (the green part in the diagram) is based on an architecture that made sense back in the earlier days of the web, but that turns out to be a major performance liability on modern pages. (It also makes compatibility with some web standards such as CSS-P near impossible.)
The other parts of the OmniWeb "engine", however, are based on a modular, multithreaded architecture that's unique among web browsers. That's why OmniWeb totals around 300,000 lines of code while Mozilla is somewhere on the order of 1.5 million lines. It's also why, despite taking a
massive performance hit on layout & display, our performance is still competitive enough with the other guys that users are continually arguing over whether OmniWeb is faster or slower than Mozilla/IE/etc.
So, how do we resolve this issue where one component of our architecture doesn't work too great, but the rest are at the top of their game? If we used Cocoazilla, we'd get the entire Netscape engine, all the way down -- not only would we lose high-level features like best-of-breed Unicode support, we'd also be taking a step backward in terms of lower-level architecture. We could attempt to use the upper layers of Gecko in tandem with our lower-level code, but trying to interface the two completely different architectures in the middle would be a massive project. It'd take far more time and effort than rewriting our own layout & display component from scratch, and we'd still be taking steps backward in certain areas (like Unicode support).
We think we can do it better, so we're going to try -- we're already rewriting our layout & display engine for 5.0. If nobody thought things could be improved upon, there would be no such thing as progress.<hr></blockquote>
[quote]Originally posted by gregomni:
I want to follow up even more on what Rick was saying...
The different layers in Rick's architectural diagram all run in independent threads, with potentially multiple copies of each type of thread if (for instance) we are loading multiple pages at once or loading multiple images on a single page, et cetera.
This all funnels together into a single 'main' thread which runs both the user interface and view layout and display. As well as all the problems already mentioned with the view layout and display piece, that 'funnel' is a pretty major bottleneck to the speed up we get for our multi-threaded architecture.
We'll be fixing this when we replace that component in OW 5. The 'funnel' will essentially move up one level higher to be right below the user interface layer. Meaning, view layout and display will no longer be competing in the same thread with user interface, which should make OW more responsive.
Anyway, what I originally wanted to get at, is that even today with our outdated view layout layer, OmniWeb is very speedy compared to other browsers if you have a dual processor machine and a fast network connection. Our multi-threading architecture lets us get more done simultaneously, if your hardware and network can support it.
I see this as a bet on the future. I think cable and DSL are going to get more common, and I think multiprocessor Macs are going to get more common (including, perhaps, quad processors on the high end). OmniWeb is architected in such a way that we can continue to benefit from additional processors and additional bandwidth -- we have a lot of headroom to grow.
The other browser architectures (at least as far as we've investigated them) are concentrating on single-threaded performance, and don't appreciably benefit from multiple processors. They also don't tend to do as much network processing in parallel, so they don't take advantage of increasing network bandwidth as much as we can.
I admit it's a little hard to imagine a world in which average people do all their web browsing with a quad processor box hooked up to a megabit per second net connection, and it's even harder to imagine those people still complaining about slow web browsing in such a world. But if they did complain, it wouldn't be about our browser. :-)<hr></blockquote>
And there's plenty more where that came from.
[ 06-24-2002: Message edited by: starfleetX ]</p>
).
