Unbelieveable! Opera Dreams it was this fast! No browser on any processor I have ever seen can load a page instantainusly as this does. Fantastic! Netscape is back!
I stopped using my mac for lots of web browsing. That's part of the reason I keep a PC on my desk as well as my mac <img src="graemlins/hmmm.gif" border="0" alt="[Hmmm]" />
A Formula 1 race car may be damn fast, but it is completely impractical to drive on city streets...
[quote]Originally posted by Proud iBook Owner 2k2:
<strong>It also depends on your network connection... if your a DSL or faster then its gonna be instant. But dial up users are gonna have ta wait....</strong><hr></blockquote>
Sorry about that I found it just under the .4 download disguised as an ftp link. But as you can see, I am having trouble launching it because of my previous .4 launch.
Help! This is very fast. I am so used to Microshit IE that it takes some getting used to this upstart stuff. But I must keep growing and changing to the fast track like all you young whippersnappers. Thanks for the great tip!
My Chimera .4 is interfering with my .5 launch attempt. Anybody know how to do what to get .5 to launch without stopping with the "Navigator is already running on this system. Only one version may be run at any time." Message?
Thanks guys! Excuse my ignorance. I have to admit that even .4 Navagator is amazingly fast.
I had the same problem with testing a site. I tried to open Navigator, Mozilla, and Netscape all at the same time. Navigator launched, but the other spit out error messages like your's.
How is it at rendering pages? I keep running into pages the only seem to render correctly in IE -- very annoying. What's even worse is that some pages that I have to use only work with the PC version of IE.
<strong>My Chimera .4 is interfering with my .5 launch attempt. Anybody know how to do what to get .5 to launch without stopping with the "Navigator is already running on this system. Only one version may be run at any time." Message?
Thanks guys! Excuse my ignorance. I have to admit that even .4 Navagator is amazingly fast.</strong><hr></blockquote>
Hi, I had the same problem and had to delete some files in ~/Library/Application Support/Chimera.
I remember being impressed with Netscape 6.22 at Dartmouth (one word: fast)
But even IE smokes NS 7 at U. RI. Netscape always sucked. Mozilla is ok but crashes even more than Chimera. The way I see it: use IE for now. Chimera/Mozilla is buggy, and Omniweb doesn't do much but look pretty. Feels weird and lacks features.
So it will be interesting to see IE 6 vs. Chimera in the coming year. I have a good feeling about Chimera. OmniWeb people should join Chimera.
<strong>OmniWeb people should join Chimera.</strong><hr></blockquote>That would be stupid. OmniWeb is nothing like Chimera. Almost ZERO of the code would be compatible.
Besides OmniWeb has far more features and functionality than Chimera does at it's current infantile state. So, why doesn't Omni just use the Gecho engine that Chimera uses? <a href="http://forums.macnn.com/showthread.php?s=&threadid=88706"; target="_blank">Here</a> is an explanation from Rick Roe of the Omni Group. I've pulled the most important posts from that thread and copied them below.
[quote]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>And what about the layout problems, missing CSS, etc. that OmniWeb suffers from? [quote]Oops... guess I didn't really cover that in my earlier post, perhaps because it almost goes without saying that if we're rewriting it from scratch we'll be rewriting it to support all current technologies.<hr></blockquote>And here's a followup from Greg (also of Omni Group fame):
[quote]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>A user made this comment regarding Greg's post: [quote]Are you saying that the architecture of OW has no advantages over the competition unless you have multiple processors and a fast network connection? Or are you saying that OW can take better advantage of either of them ... but it really flies if you have both<hr></blockquote>To which Rick responded: [quote]The latter.
In the classical web browser architecture, various software components (image decoding, image rendering, HTML parsing, etc.) are often stuck waiting for data to arrive from the network while other components have data that they could be processing. In OmniWeb, we can actually be processing multiple tasks at once. Of course, on a single processor system, we can't really be doing two things at once, but we still tend to see some improvement because the Mach kernel's thread scheduling works so well compared to having the app make its own pithy attempt at task scheduling -- we're far more likely to be fully utilizing the CPU instead of waiting for data even though data is there to be processed.
Of course, letting the kernel do the scheduling gives us a couple of other benefits, too: We don't have to write and maintain as much of our own scheduling code, for one. And it means we'll automatically scale to fully utilize as many CPUs as are available -- whether it's one or two or twenty -- to get work done faster. (Now watch, someone's going to read this and assume Apple seeded us with a 20-processor Über-Xserve or something equally silly... )
This architecture doesn't work all that great on slow network connections, partially because it has a tendency to gorge itself: it'll ask for as many simultaneous network connections as the CPU can handle and end up overloading the narrow bandwidth capacity. But one of the things we intend to look into post-4.1 is finding ways to have the engine more intelligently "tune" itself to make the best use of available networking resources. Should be interesting research for whoever takes it up.... I'll be busy making sure the 5.0 user experience kicks butt.<hr></blockquote>
There is some more good info in that thread, but I'll stop quoting now and let you go see for yourself if interested.
This one From Dave Hyatt, Mozilla engineer and former head of Chimera development: [quote]I don't think it makes sense for Omniweb to use Gecko at all.
I chose the name Chimera based off the following definition from m-w.
an imaginary monster compounded of incongruous parts
Gecko is a thick cross-platform codebase that doesn't reuse components that have already been implemented by the OS. It implements all its own data structures in C++, from strings to hashtables. It implements its own URL class, its own networking layer, a complete widget library that has to wrap the native representation (Cocoa NSViews), etc. etc. The code is immense (over 1.5 million lines) and hard to understand. It's hopelessly entangled. It wrongly uses a thick reference counting system called XPCOM to communicate even in the guts of the networking layer and layout engine, forcing you to pay a reference counting churn penalty (Obj-C does not have this problem, because it doesn't burden the caller with the duty of releasing a reference count augmented by the callee). Its threading model is extremely weak, managing only to push network fetching onto a separate thread, while hogging the UI thread for image decoding, parsing, document tree construction, rendering tree construction, script execution, style resolution, and rendering. Gecko forces you to pay a huge startup time penalty because of its enormous code footprint. Chimera's startup time is slower than either Omniweb or IE.
We're also having to wrestle with the cross-platform nature of Gecko, which makes it hard for us to do anti-aliased text without taking a huge speed hit. Our form controls are ugly because they don't use real native controls (we cheat by using the Appearance Manager). Our selection behavior doesn't fit in right with the OS X platform because Gecko implemented selection itself in cross-platform code, nor does our drag and drop behavior for the same reason. The problems mentioned in this paragraph are all surmountable, but they'll take time.
You also pay a "copy tax" crossing the Obj-C/C++ boundaries. Chimera's control presents an Obj-C interface to the world, but underneath it has to convert everything into Gecko's data structures. An NSURL has to become an nsIURL. An NSString has to become an nsString. And so on.
About the only thing Gecko has going for it is correctness and a very large range of implemented standards, but I'd rather see someone try to do it better. A browser on OS X done right should be able to dust Gecko in terms of speed and footprint. It should be able to just smoke Gecko in startup time and page load time. The fact that this hasn't been done yet doesn't mean it can't be done.<hr></blockquote>
And for the uninitiated, a few definitions/explanations:
Mozilla = an open source project for the browser
Netscape = USES MOZILLA as the core, only changing the logo, name, and built-in chat client.
Gecko = the engine behind the Mozilla browser project
Chimera = uses the Gecko core engine inside a Cocoa "skin" app
I know. But in my experience OmniWeb blows. There's no room for another browser besides IE unless it's incredibly better, since IE is "Good Enough?"
OmniWeb is not that. Unless they have a fast-track of bitchin' updates planned they're gone. Netscape was never good, and I don't know why anyone in their right mind would use it.
Chimera looks like it will be amazing in a year. I say this predicting Apple will make an iBrowser out of it
Personally, based on my experiences so far, I think OmniWeb will be the best browser in the future. What I just read makes me believe that even more now.
I just joined the Net7 party (BTW, I'm still using OS9.x), and everything seems to be going good! Bouncing back and forth to cached pages does seem a bit faster than Net6 (and Net6 was fast enough to be "adequate", IMO). It is on the verge of the IE sort of refreshes, which is a good thing to say.
The potential difference is when you have more than a few pages loaded-up. With my usual 7 pages loaded-up, Netscape responsiveness seems to be staying snappy. We shall see if it stays that way after it has been running for 2 days. IE OTOH, tends to get bogged down when I load-up my 7 pages and use them for a while. Responsiveness and bouncing back/forth to cached pages can get inconsistent in speed to outright fustrating as it sits there struggling on who knows what.
The thing that really impresses me most about Net7- these cool, cool tabbed windows! I know it has been mentioned before, but these things are terrific. No more screen clutter with 7 pages fighting for real estate. No more repositioning/resizing windows. It's all automatically organized and accessible from the tab bar. Netscape has matured well, and now has a version worthwhile for "resilent" Net4.x and Net6 users to step over to with regard to speed and features.
The only problem I've noticed so far is occasionally the mouse pointer leaves artifacts when I wheel scroll a page. That may have more to do with Kaleidoscope compatibility than Net7 itself. Anybody else seeing this?
Overall, this is THE best Netscape I have seen, yet. It is worthwhile for my primary, fulltime use (and I have been using IE prior to that). Assuming there are no problems down the line with crashes (I am somewhat concerned over me trying out a x.0 release- I should know better), I should be a happy camper.
My vote goes to OmniWeb. I've heard all kinds of things about how slow it is, but on a 56k you don't notice the difference. Using system spelling makes it good for these forums. It uses the normal OS X widgets. I am a whore for Cocoa toolbars...and OmniWeb has quite a nice selection of buttons to customize it with. The antialiasing is great, and doesn't seem to corrupt and screw up like IE. Personally, I can't stand NS, Chimera, and iCab because their font rendering sucks. NS and Chimera may be 'fast' but they take a lifetime and a half to load.
Moz and Net6/7 don't have a "down" scroll button on the bottom right of the screen in either 10.1.4 or 9.2.2 Damn bugs 'n' bloat. Still fills so unfinished. Anyone else see this weird bug? Annoys the hell out of me when I don't have my scroll mouse with me!
I'm worried what happened to Opera will happen to OmniWeb. It will be surpassed be IE or Moz or both and become marginalized, even more a minority. Apple should buy them
Comments
In terms of shear rendering speed (nothing else):
1. Chimera .5
2. Chimera .5 (just for effect)
3. Mozilla 1.1
4. Netscape 7
5. IE
6. Omniweb 4.x
A year from now, most likely:
1. Chimera 1.x
2. Omniweb 5.x (brand new render engine)
3. Mozilla 1.7ish
4. Netscape 8
5. IE 6? (new engine? death of IE for Mac before then?)
6. ??
[ 09-06-2002: Message edited by: Moogs ]</p>
A Formula 1 race car may be damn fast, but it is completely impractical to drive on city streets...
<strong>It also depends on your network connection... if your a DSL or faster then its gonna be instant. But dial up users are gonna have ta wait....</strong><hr></blockquote>
on windows side too
<a href="http://chimera.mozdev.org/installation.html"; target="_blank">http://chimera.mozdev.org/installation.html</a>;
Sorry about that I found it just under the .4 download disguised as an ftp link. But as you can see, I am having trouble launching it because of my previous .4 launch.
Help! This is very fast. I am so used to Microshit IE that it takes some getting used to this upstart stuff. But I must keep growing and changing to the fast track like all you young whippersnappers. Thanks for the great tip!
[ 09-06-2002: Message edited by: Multimedia ]</p>
Thanks guys! Excuse my ignorance. I have to admit that even .4 Navagator is amazingly fast.
I had the same problem with testing a site. I tried to open Navigator, Mozilla, and Netscape all at the same time. Navigator launched, but the other spit out error messages like your's.
I DO like Mozilla 1.1 and may try Chimera when it's out of alpha...just as I did with Mozilla.
But believe me...R.I.P. Netscape.
<strong>My Chimera .4 is interfering with my .5 launch attempt. Anybody know how to do what to get .5 to launch without stopping with the "Navigator is already running on this system. Only one version may be run at any time." Message?
Thanks guys! Excuse my ignorance. I have to admit that even .4 Navagator is amazingly fast.</strong><hr></blockquote>
Hi, I had the same problem and had to delete some files in ~/Library/Application Support/Chimera.
I remember being impressed with Netscape 6.22 at Dartmouth (one word: fast)
But even IE smokes NS 7 at U. RI. Netscape always sucked. Mozilla is ok but crashes even more than Chimera. The way I see it: use IE for now. Chimera/Mozilla is buggy, and Omniweb doesn't do much but look pretty. Feels weird and lacks features.
So it will be interesting to see IE 6 vs. Chimera in the coming year. I have a good feeling about Chimera. OmniWeb people should join Chimera.
<strong>OmniWeb people should join Chimera.</strong><hr></blockquote>That would be stupid. OmniWeb is nothing like Chimera. Almost ZERO of the code would be compatible.
Besides OmniWeb has far more features and functionality than Chimera does at it's current infantile state. So, why doesn't Omni just use the Gecho engine that Chimera uses? <a href="http://forums.macnn.com/showthread.php?s=&threadid=88706"; target="_blank">Here</a> is an explanation from Rick Roe of the Omni Group. I've pulled the most important posts from that thread and copied them below.
[quote]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>And what about the layout problems, missing CSS, etc. that OmniWeb suffers from? [quote]Oops... guess I didn't really cover that in my earlier post, perhaps because it almost goes without saying that if we're rewriting it from scratch we'll be rewriting it to support all current technologies.<hr></blockquote>And here's a followup from Greg (also of Omni Group fame):
[quote]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>A user made this comment regarding Greg's post: [quote]Are you saying that the architecture of OW has no advantages over the competition unless you have multiple processors and a fast network connection? Or are you saying that OW can take better advantage of either of them ... but it really flies if you have both<hr></blockquote>To which Rick responded: [quote]The latter.
In the classical web browser architecture, various software components (image decoding, image rendering, HTML parsing, etc.) are often stuck waiting for data to arrive from the network while other components have data that they could be processing. In OmniWeb, we can actually be processing multiple tasks at once. Of course, on a single processor system, we can't really be doing two things at once, but we still tend to see some improvement because the Mach kernel's thread scheduling works so well compared to having the app make its own pithy attempt at task scheduling -- we're far more likely to be fully utilizing the CPU instead of waiting for data even though data is there to be processed.
Of course, letting the kernel do the scheduling gives us a couple of other benefits, too: We don't have to write and maintain as much of our own scheduling code, for one. And it means we'll automatically scale to fully utilize as many CPUs as are available -- whether it's one or two or twenty -- to get work done faster. (Now watch, someone's going to read this and assume Apple seeded us with a 20-processor Über-Xserve or something equally silly...
This architecture doesn't work all that great on slow network connections, partially because it has a tendency to gorge itself: it'll ask for as many simultaneous network connections as the CPU can handle and end up overloading the narrow bandwidth capacity. But one of the things we intend to look into post-4.1 is finding ways to have the engine more intelligently "tune" itself to make the best use of available networking resources. Should be interesting research for whoever takes it up.... I'll be busy making sure the 5.0 user experience kicks butt.<hr></blockquote>
There is some more good info in that thread, but I'll stop quoting now and let you go see for yourself if interested.
[ 09-06-2002: Message edited by: Brad ]</p>
This one From Dave Hyatt, Mozilla engineer and former head of Chimera development: [quote]I don't think it makes sense for Omniweb to use Gecko at all.
I chose the name Chimera based off the following definition from m-w.
an imaginary monster compounded of incongruous parts
Gecko is a thick cross-platform codebase that doesn't reuse components that have already been implemented by the OS. It implements all its own data structures in C++, from strings to hashtables. It implements its own URL class, its own networking layer, a complete widget library that has to wrap the native representation (Cocoa NSViews), etc. etc. The code is immense (over 1.5 million lines) and hard to understand. It's hopelessly entangled. It wrongly uses a thick reference counting system called XPCOM to communicate even in the guts of the networking layer and layout engine, forcing you to pay a reference counting churn penalty (Obj-C does not have this problem, because it doesn't burden the caller with the duty of releasing a reference count augmented by the callee). Its threading model is extremely weak, managing only to push network fetching onto a separate thread, while hogging the UI thread for image decoding, parsing, document tree construction, rendering tree construction, script execution, style resolution, and rendering. Gecko forces you to pay a huge startup time penalty because of its enormous code footprint. Chimera's startup time is slower than either Omniweb or IE.
We're also having to wrestle with the cross-platform nature of Gecko, which makes it hard for us to do anti-aliased text without taking a huge speed hit. Our form controls are ugly because they don't use real native controls (we cheat by using the Appearance Manager). Our selection behavior doesn't fit in right with the OS X platform because Gecko implemented selection itself in cross-platform code, nor does our drag and drop behavior for the same reason. The problems mentioned in this paragraph are all surmountable, but they'll take time.
You also pay a "copy tax" crossing the Obj-C/C++ boundaries. Chimera's control presents an Obj-C interface to the world, but underneath it has to convert everything into Gecko's data structures. An NSURL has to become an nsIURL. An NSString has to become an nsString. And so on.
About the only thing Gecko has going for it is correctness and a very large range of implemented standards, but I'd rather see someone try to do it better. A browser on OS X done right should be able to dust Gecko in terms of speed and footprint. It should be able to just smoke Gecko in startup time and page load time. The fact that this hasn't been done yet doesn't mean it can't be done.<hr></blockquote>
And for the uninitiated, a few definitions/explanations:
Mozilla = an open source project for the browser
Netscape = USES MOZILLA as the core, only changing the logo, name, and built-in chat client.
Gecko = the engine behind the Mozilla browser project
Chimera = uses the Gecko core engine inside a Cocoa "skin" app
[ 09-06-2002: Message edited by: Brad ]</p>
OmniWeb is not that. Unless they have a fast-track of bitchin' updates planned they're gone. Netscape was never good, and I don't know why anyone in their right mind would use it.
Chimera looks like it will be amazing in a year. I say this predicting Apple will make an iBrowser out of it
The potential difference is when you have more than a few pages loaded-up. With my usual 7 pages loaded-up, Netscape responsiveness seems to be staying snappy. We shall see if it stays that way after it has been running for 2 days. IE OTOH, tends to get bogged down when I load-up my 7 pages and use them for a while. Responsiveness and bouncing back/forth to cached pages can get inconsistent in speed to outright fustrating as it sits there struggling on who knows what.
The thing that really impresses me most about Net7- these cool, cool tabbed windows! I know it has been mentioned before, but these things are terrific. No more screen clutter with 7 pages fighting for real estate. No more repositioning/resizing windows. It's all automatically organized and accessible from the tab bar. Netscape has matured well, and now has a version worthwhile for "resilent" Net4.x and Net6 users to step over to with regard to speed and features.
The only problem I've noticed so far is occasionally the mouse pointer leaves artifacts when I wheel scroll a page. That may have more to do with Kaleidoscope compatibility than Net7 itself. Anybody else seeing this?
Overall, this is THE best Netscape I have seen, yet. It is worthwhile for my primary, fulltime use (and I have been using IE prior to that). Assuming there are no problems down the line with crashes (I am somewhat concerned over me trying out a x.0 release- I should know better), I should be a happy camper.
[ 09-06-2002: Message edited by: Randycat99 ]</p>
</rant>
<img src="graemlins/smokin.gif" border="0" alt="[Chilling]" />
I'm worried what happened to Opera will happen to OmniWeb. It will be surpassed be IE or Moz or both and become marginalized, even more a minority. Apple should buy them