Chrome Vs. IE 8 771
snydeq writes "Google Chrome and Internet Explorer 8 herald a new, resource-intensive era in Web browsing, one sure to shift our conception of acceptable minimum system requirements, InfoWorld's Randall Kennedy concludes in his head-to-head comparison of the recently announced multi-process, tabbed browsers. Whereas single-process browsers such as Firefox aim for lean, efficient browsing experiences, Chrome and IE 8 are all about delivering a robust platform for reliably running multiple Web apps in a tabbed format in answer to the Web's evolving needs. To do this, Chrome takes a 'purist' approach, launching multiple, discrete processes to isolate and protect each tab's contents. IE 8, on the other hand, goes hybrid, creating multiple instances of the iexplore.exe process without specifically assigning each tab to its own instance. 'Google's purist approach will ultimately prove more robust,' Kennedy argues, 'but at a cost in terms of resource consumption.' At what cost? Kennedy's comparison found Chrome 'out-bloated' IE 8, consuming an average of 267MB vs. IE 8's 211MB. This, and recent indications that IE 8 itself consumes more resources than XP, surely announce a new, very demanding era in Web-centric computing."
Re:How Ironic (Score:1, Informative)
irony (plural ironies)
Re:"Thin" won't be "in" (Score:4, Informative)
Standards (Score:4, Informative)
Re:How Ironic (Score:5, Informative)
IE8 consumes more resources than Vista? (Score:4, Informative)
Re:Not hard to get... (Score:3, Informative)
Unless you have a 64-bit OS, you're limited in how much of that 6 GB of RAM you can actually use. I forget the exact limit, but I think you'll only be using ~3 GB of that due to various legacy hardware issues
There is some lie in your truth, and some truth in your lie. Or something like that.
The upper limit on 32-bit addressing is 2^32 = 4294967296 bytes. Which is, coincidentally, exactly 4 gigabytes. Any 32-bit copy of Windows can support up to that much.
Why, then, do some computers only report 3 GB of RAM available? It's not really lost - it's just a side effect of how Windows handles memory paging. Every program running on Windows is going to be using at least some part of the Windows API, so Windows reserves a portion of RAM for its own system files and locks it. (Why would you swap system libraries used by nearly every application out to disk? Ever?)
Additionally, this RAM gobbled up by Windows is mapped to every process. 512 MB or 1 GB isn't really "missing" - in fact, it's part of the shared memory space of every process, and every process can address it as if it really did own it.
The overlapping memory pages is kinda cool, but your computer actually is using all of that RAM you installed. Discrepancies depend on your motherboard logic, exactly how Windows decides to address that "missing" memory space (I honestly don't know what Windows does sometimes), and the presence or absence of Physical Address Extension hardware. (If your motherboard supports it, the Pentiums and up actually have pins for 36-bit memory addressing, which is why you can see computers in Circuit City running 32-bit Vista and reporting 4 GB (or more) of memory. Cheaper CPUs or motherboards just won't connect the extra pins, and you won't see a "PAE Enabled" or whatever in My Computer->Properties.)
Discuss!
Not Accurate (Score:4, Informative)
The description of the process model isn't that accurate. In both IE8 and Chrome the renderer process is shared across multiple tab groups. If you manually create a new tab that tab will have a new rendering process associated with it. If you click on a link and it opens in a new tab it will share the rendering process of the parent page. Chrome will show you this in the Task Manager as a single process which show a list of tabs.
The implementation of the rendering processes between IE8 and Chrome are strikingly similar, so much so that I am suspicious that Google borrowed some ideas from the public betas of IE8 which had this functionality since March. Both use the same behavior for sharing rendering processes as mentioned above. Both spawn the same image as the rendering process as the hosting browser process (iexplore.exe and chrome.exe), using command line arguments to pass channel information. Both use the Job API in Win32 to assign the rendering processes to security restricted jobs. Both use an IPC mechanism built on UDP messaging to localhost for the rendering processes to communicate back to the parent process, where plenty of other IPC options exist, and considering a lot of the Chrome code is Win32-specific they could have used platform-specific IPC for performance purposes without sullying the project.
Where Chrome differs is that unlike IE8 plugins are also loaded in isolated processes. It's a neat idea in theory but I think it will be problematic in practice. The browser shares one plugin process for all uses of that plugin, which I've already seen cause bottlenecks in resources on my machine trying to view several sites with Flash content. The plugin processes also have a lot of hard coded logic to deal with the nuances of the different plugins and how they behave. For example, there is hard coded logic to deal with the UI expectations of Flash where the content is rendered in the renderer process instead of in the plugin process, whereas with QuickTime the content is rendered in the plugin process and overlaid in the rendering process. In IE8 if a plugin crashes hard the tabs that contain the failing plugin would crash, but other pages would remain open potentially displaying other content using the same plugin. In Chrome if the plugin crashes hard it does so for every page displaying content with that plugin, although all of the tabs would remain loaded showing a placeholder where the content would be.
Re:Hmmm (Score:4, Informative)
You are correct. Linux, Windows, and pretty much all modern operating systems implement copy-on-write.
Re:Firefox Damage Control Is More Than Enough (Score:2, Informative)
Firefox's set of extensions and features are very, very important to a "Web 2.0" user for whom the Chrome is meant. As it stands today, Chrome is a bloody useless browser, and it looks butt-ugly to boot. If I wanted Webkit and its semblance of speed, I'd just get myself a Safari, no?
Re:Didn't measure memory correctly (Score:0, Informative)
Threads do not have separate address spaces so they don't require fancy memory-management tricks like separate processes do.
Re:Firefox Damage Control Is More Than Enough (Score:5, Informative)
Wrong Measurements (Score:1, Informative)
The test is not correctly measuring the memory usage of the browser. What he's reporting is the "working set" of each process which includes memory mapped binary images, including the browser binaries themselves. For each rendering process, for both Chrome and IE8, the working set would reflect the entire loaded code base. However, that memory is shared between all processes so the numbers are very inaccurate.
My experience is that Chrome uses about 6 MB of overhead per tab. For IE8 that number is around 15MB. If you're loading different sites those resources are also private bytes to the rendering process. For example the process handling the rendering of the two Slashdot tabs I currently have open is using 8MB of RAM. The process handling rendering of Microsoft.com and the Chrome DOM inspector is using 26MB of RAM. The process handling the Flash plugin is using 32MB of RAM.
Re:Google Chrome HDD and CPU Usage (Score:4, Informative)
Somebody I know had this happening to them, turning off the malware/phishing site definition files being downloaded fixed this (it downloads a new file about every 3 seconds if you look at about:network)
Re:Not hard to get... (Score:5, Informative)
This is not entirely true. Normally the BIOS will remap IO address space above system RAM, but on 32 bit hardware (with or without PAE), the BIOS will generally reserve a hole somewhere between 3GB and 4GB. Depending on your specific hardware, this hole might be pretty big. For instance, if you have a 512MB video card, that memory gets mapped into the system address space, and you lose the same amount of system RAM for the privilege. There are some BIOS that will allow you to map this memory above 4GB but drivers sometimes flake out when you do that; plus you have to run a 64bit OS at that point too.
You will never see a 32 bit vista machine report more than 4GB of ram as it's simply not supported. (Makes you wonder why they turn on PAE by default since it slows down memory access?? A vendor turning PAE off is probably just smart.) You will, however, see vista report 4gb in the computer properties -- but it's more of a marketing trick. 32 bit windows will only allocate 2GB of address space to user processes anyway and 3GB only with a special boot switch (that you have to be careful with.)
As far as your claim that some cheap motherboards do not connect the PAE pins, that's also somewhat misleading too -- the pins are all there anyway -- its just the feature was left out of cheap junk northbridge chipsets... but this was back in the Pentium III days. It's very doubtful you can even find a board anymore that does not support PAE; especially since pretty much all current model CPU's have 64 bit support.
Re:Resources? (Score:5, Informative)
e.g. Just open youtube and play any video. Now, Chrome Task manager shows three 'processes' - each with memory footprint and CPU usage - One for Browser, one for Tab, and one for Flash Plug-in. You can not kill the Browser process, but you can kill any other.
For more details, you can type "about:memory" in the URL and see what's going on in more details.
Re:I don't get it. (Score:3, Informative)
Memory is owned by the process, so killing off a thread for a tab won't help you. Worker processes is a traditional form of resiliance for app servers like IIS (presumably Apache too).
Operating systems have already solved the problem of isolation of tasks (processes) so it seems appropriate to use this functionality. Memory is cheap - I put 4gig in a laptop for under a hundred bucks. IE8 seems to be putting more effort into saving memory than Chrome, but TBH I don't think its worth the effort.
An advantage of 64-bit Linux? (Score:5, Informative)
I only use 64-bit Linux these days. Since Flash isn't 64-bit yet, it runs in a separate process from my 64-bit browser, thanks to nspluginwrapper.
The only problem is, when it does crash, it doesn't restart until I restart my browser. So, my browser is fine, but I won't be watching any more YouTube. Better than a crash, but not as good as it could be. If anyone knows enough about nspluginwrapper to fix this, it would be awesome -- maybe even for 32-bit users.
I believe Chrome does this, too -- but I would hope that, since they've done it deliberately, as a way to minimize the damage a plugin can do, they would also be able to handle plugin crashes more gracefully than requiring a full browser restart.
Re:Firefox Damage Control Is More Than Enough (Score:5, Informative)
Re:Not hard to get... (Score:5, Informative)
Mostly Wrong. The reason you don't see all 4 GB on Windows machines is a combination of 2 factors.
#1. Memory mapped devices. This includes device which has onboard RAM (video card is biggest factor with the 1GB of RAM that's usual now). This must be mapped somewhere in the physical address space (virtual address space is irrelevant for this issue). And for compatibility with 32-bit DMA purposes has to be below the 4GB mark. So modern motherboards will remap the "displaced" RAM above the 4GB mark so it is still accessible.
Now onto issue #2. Windows *could* use PAE to access this relocated RAM, but it doesn't on desktop editions (even if PAE is enabled). Technically from a hardware point, it should be accessible, but once again for compatibility purposes, the Microsoft folk have opted to simply not use any RAM seen above the 4GB mark. The reason why is because of poorly programmed 3rd party drivers which assume all RAM is below 4GB, and try to do 32-bit DMA (and thus trash random memory and crash the system). For Microsoft, it's easier to simply avoid the issue then explain why it's not there fault to customers. (BTW server editions are a different story and DO support using RAM above 4GB).
You can verify this by opening up Microsoft's "System Information" utility and going to the "Memory" section. Simply put, it does not show ANY memory above 0xffffffff despite the fact that I know for a fact that there is RAM mapped above that address (installing Linux with "64GB memory support", aka PAE support, shows this to also be true and DOES report and using all 4GB of my RAM).
This issue has NOTHING to do with "shared memory space between processes.
Re:We need to go in the other direction (Score:3, Informative)
search application...
I'm sorry, but I must have missed the memo where Google Desktop was supposedly installed alongside Chrome.
You were probably better off reading the comic rather than watching a bunch of Mac-style videos. The key stuff Chrome brings to the table are: (1) Process isolation per open tab and plugin, with a task manager to kill processes that misbehave, (2) new Javascript engine complete with JIT precompiler. Now if you're browsing with FF nightlies, you might already have a snazzy new JS engine. But a crashed tab still brings down your session with it. I've read blog posts and commentary about how you can type in some obscure remote mode Firefox command to get the multiprocess benefits, but unless Firefox makes that standard-- and that's a pretty fundamental design change-- Chrome has an advantage in terms of stability.
At least, until people start spamming Chrome users through Gears.
Re:We need to go in the other direction (Score:3, Informative)
The tabs hit the top of the screen for me in XP (when the browser is in full screen mode).
Re:But we can already crash EVERY tab at once (Score:2, Informative)
Weird. Just copying "evil:%" into the clipboard and right clicking on the URL bar in chrome does the same thing.
Re:An advantage of 64-bit Linux? (Score:3, Informative)
Re:Chrome iPhone (Score:5, Informative)
IE8 with 6 processes was using 958524 KB and Chrome with 11 processes was using 783840 KB.
Uhm, how are you counting that? There are 11 Chome.exe processes, and when you add their "Mem Usage" columns up you get 783840KB? Because, er, OS's which use paged memory VM's don't work like that; about the only way you can really work out how much memory they're all using is by comparing their VM mappings and seeing what bits are shared between them (and not also with other processes; e.g. standard Win32 dll's everyone uses) and which aren't.
This is why Chrome has about:memory, with an *estimate* of how much memory Chrome is using; if I spawn 11 tabs and add up Mem Use, I get 263MB. about:memory, however, estimates it's using 166MB, and a good chunk of that may well be in memory mapped files and as easily disposable as filesystem cache.
Re:Not hard to get... (Score:1, Informative)
PAE has to be enabled to get the NX (no-execute) to work as it resides in bit 63 of the page table entry. Without PAE those entries would have only 32 bits and NX wouldn't work.
Re:Firefox Damage Control Is More Than Enough (Score:1, Informative)
Konqueror uses Webkit, as of several months ago.
Re:Firefox Damage Control Is More Than Enough (Score:3, Informative)
I've been using Chrome since it became available and I really don't think the "big memory footprint" is an issue at all. I have only 512MB of RAM on the machine I'm running it, and it hasn't slowed it to a crawl the way other browser did. FF2 was gawdawful in that regard.
Chrome has out of the box some basic features that are really useful and ought to be default in others —cough-FF3,IE-cough— such as spell check enabled by default and the ability to resize text boxes on the fly. Plus its garbage collection and memory handling so far seem superb. I really ache to compare FF3 against Chrome, I'm torn between the lightning-fast Google browser and the amazing customization capabilities of Mozilla's.
Other than the lack of extensions that other posters have mourned, the only problem I've found so far is that it doesn't like something about my auto-configuration proxy file (it shares the same one as IE by default). FF3 doesn't like it either but add FoxyProxy and voila, browse away.
I was impressed that Chrome was able to work out of the box with one Citrix. It didn't ask to download or install anything, it just did. Same goes for flash. I haven't figured out yet whether it uses FF's or IE's plug ins for this, I wouldn't be surprised that it can use either or them.
All in all, this is a very solid beta and it has a promising future. But as the Mozilla guys pointed out, Firefox is not dead yet. I just installed yesterday their Ubiquity tool... if there was an Ideal browser it would be Chrome with Firefoxe's add ons. They can't cross-pollinate soon enough.
Re:Firefox Damage Control Is More Than Enough (Score:1, Informative)
But Firefox is a feature-rich, mature browser, lean in itself, but with lots of add-ons tailored to individuals with individual requirements.
Are you kidding me?
Firefox is anything but feature rich, and only functional when you spend a bunch of time researching and downloading plugins. It's bare bones and crappy without at least 5-10 plugins.
And lean it is not. Wow, I mean, not even close.
Right now, I've got Opera, Firefox and Chrome running.
Firefox had 38 tabs open, Opera has 33, and Chrome has 5. Opera has been running the longest.
Firefox (v3, after they've 'solved' all the memory leaks) us using ~360M private bytes.
Opera is using ~160M, and Chrome is using ~125M.
It's improved, as firefox2 in this usage scenario would climb to over 1GB of private bytes before long, whereas now with 3 it seems to plateau for my usage at about 500M.
Re:Chrome iPhone (Score:3, Informative)
Just use the 'Private Bytes' in windows, and that'll give you what you need.
Thats what you see by default in Vista's task manager, and in the Chrome task manager.
Task managers have inaccurate memory reports (Score:2, Informative)
If I may be so bold.
This is where it's at:
Windows has something call Dynamic Link Libraries (aka DLL's)
The aim of a DLL is to share code amongst processes. So if Chrome's multiprocess model loads the same DLL multiple times, it maps the DLL's code into the address space of the calling process. Let's pretend for the sake of argument that the rasterization DLL is 10 megabytes large. This means that the shared 10mb DLL is shared between all the processes, and that in fact you should be measuring the shared DLLs. Just because Task Manager (or similar tools) measure 6x50mb processes, this does not mean that each process is physically consuming 50mb of RAM. It means it has 50mb mapped to it. Windows (and any sufficiently advanced operating system with delay-load code systems) follows a scheme called Reference Counting, where a DLL is loaded when referenced the first time and a counter incremented that says "hey, now 1 process is using me"
After that, each successive process loads the DLL and also indirectly ups its reference count. When all processes that load the DLL end, the DLL remains loaded in memory until the OS garbage collects it.
One must always question the tools he uses to measure the efficiency of programs. What you really want is to see the difference between process-local and process-mapped heap allocation statistics, as this is a truly accurate count of memory usage.
Furthermore; IE8 is in beta. Chrome is in beta. And before all you firefox fanbois go off about "yeah but look at firefox's memory use when it was in beta!" I have one thing to say: Firefox is based on netscape. Which has been a little out of beta for more than 5 years. (probably in excess of 10 years). Chrome is new. And HIGHLY feature-packed. and it is NOT bloated. just because there's a high memory use report in a task manager, this does not mean that the use is high. I'm disappointed in you guys, I thought this was a geek forum, where people question everything?
Re:BloatWare Continues.... (Score:3, Informative)
Chrome is not smaller or less bloated than IE or Firefox. Chrome is intentionally bloated, in the measure of memory consumption. They choose to trade space (memory) for stability and reliability.
Chrome RAPIDLY consumes much more memory than IE or Firefox when using equivalent number of tabs/pages/apps.
Re:Firefox Damage Control Is More Than Enough (Score:5, Informative)
Konqueror uses Webkit, as of several months ago.
Correction: Konqueror can be compiled to use QtWebKit, but out of the box it still uses KJS/KHTML from the KDE Devs. If you don't believe me then check yourself on Debian or other distributions.
Re:Security improvements? (Score:4, Informative)
it's not an exploit. you cannot call it that because its a beta product. Beta products have bugs. its the same as a test driver saying a car is crap because feature is not correct. By downloading and using chrome, you submit to being a beta tester. if you're going to go around spreading negative publicity about a beta product that you are technically a tester of, in order to improve it, then you're a moron. call me a flametroll. just don't come post "0day sploits" about a beta product, because thats retarded.
Re:Standards (Score:3, Informative)
You do realize that ACID isnt an actual conformance test of any standard, right?
It's something that 'some guys' put together, and seemed reasonable enough (in a world with no reference implementation or conformance tests) that its gotten some mind share.
In addition, Acid2 is a much better representation of things actual web designers will do. Acid3 is a little out there, IMO.
And dont forget the phenomenon of browsers being optimized to Acid test, rather than actual real-world usage. Similar to what happened in the graphics card world. Companies optimized for the specific tests used by reviewers, rather than real world use.
Re:Enough! (Score:3, Informative)
If you believe their comic book that the memory is separate, that means the images and most resources for a page are also separate. So when you have ten tabs of the same site then you have multiple copies of the same images in memory (page header, favicons, etc).
Yes and No. Processes are forked using copy-on-write, with shared memory between parent and child processes.
Process data is different, process image (for the most part) isnt.
So yes, 10 copies of the same page will have lots of duplicate data. But thats not a common case. The common case, where 10 tabs have all different page, its no different memory situation.
It's also possible they're doing some smart optimizations for duplicate pages, particularly if the duplicate tabs are in the same parent process.
Chrome's isolation approach (in contrast to IE8) is like a microkernel... fault tolerant, but with a LOT of resource overhead and programmer overhead (communicating, coordinating settings between main process and tab processes).
Everything I've seen and read, IE8 and Chrome are strikingly similar in their architecture. Surprisingly so, in fact.
The trade-offs for multi-process vs. multi-threading are well known. I would strongly argue that they made the right architecture choice for 3-5 years from now. Whereas FF in its 1-process only will become harder and harder.
Multi-threading can be fast at best, but is hideously complicated to do well with large amounts of threads and shared memory. It's incredibly error prone, from the programmers point of view.
Multi-processing is much simpler to write, but is slower in IPC and forking (the latter especially on windows). But its also much simpler to write simple, low-bug code, and make the system reliable over a long term.
It's also quite arguable that the performance hits from an IPC based system are not relevant in an app like a browser.
So ultimately you're going to be disappointed with Chrome if you're looking for performance. If you want fault tolerance, sure
Depends what you mean by performance. Chrome will have a higher peak memory usage (in typical scenarios) but will likely have much better memory behavior over the long term, as many tabs and pages are opened and closed. The multi-process approach fundamentally leads to simpler and more effective memory management.
but in general a failure that crashes the browser can be exploited. Loosing your email is kind of trivial compared to having a bot ruin your system, so the best is just not to crash (iow, write as much of the browser in possible in javascript).
I think you're misunderstanding a couple things here, at least with Chrome on windows.
1. Chrome runs with the same sandbox and process isolation (ie, less rights than a non-admin user) as IE7 and IE8 on Vista. Just this makes it much more resilient than FF would be, as FF runs as your user, so anything that penetrates the browser barrier has the same perms as you. Something that penetrates the Chrome barrier doesnt even have write access to your profile, much less to the system.
2. Chrome's architecture, once it gets out of beta, is going to make it MUCH less prone to crashing than FF. It's a fundamentally more robust architecture. Plus, the coding is simpler in that architecture, so its easier for the devs to make more stable code. It's a win-win, other than peak memory usage, and IPC related speed issues.
3. Writing the browser in JavaScript wont make something less prone to crashing. JavaScript execution is inherently attackable, as is anything that results in code generation, JIT'ing, etc behind the scene. The recent set of attack techniques that use predictable stack and heap allocation techniques (the ones that attack far past the initial entry points) rely heavily on Java, .NET and JavaScript type of engines to work.
Re:Security improvements? (Score:4, Informative)
Could you not be bothered to read the links you posted?
The first one is not a security exploit. It's at most a DoS since it causes the app to crash.
The second one is an old/known vulnerability in webkit. Of course they inherited it. It's exactly the same problem called the 'carpet bombing vulnerability' in Safari, which also uses webkit.
Re:Read the EULA (Score:3, Informative)
They already responded to this and will be taking this out. Its on arstechnica.
Their lawyers do what nearly all businesses do and re-use legal agreements like EULAs.
So they had a standard one and they used it. No one but a lawyer looked at it in detail, and the lawyer likes those nasty terms.
Anyway, I'm speculating. But they've publicly announced that its an oversight and they'll re-write it to remove that.
Resources (Score:5, Informative)
are there to be used.
I'm old enough to remember this kind of argument about assembler vs. compiled languages. Hand coded assembler will always be smaller, and for any given algorithm it will very likely be faster. When viewed as assembler it will always be more elegant.
From time to time one comes across an assembly language application (although it's a lot rarer these days) that is a tour de force, doing the essential tasks of its compiled competitors in a fraction of the space and often noticeably more snappily. But they aren't notable for the breadth of features they offer.
And that's what bloat is about. Bloat isn't about using resources; it's about devoting resources to ideas that seemed like a good idea at the time but which you don't have the time or ability to undo. Sometimes the feature doesn't exist yet, or abandoned, but still leaves its mark. The reason that large assembler programs tend to be lean isn't so much that humans produce tighter code than compilers, although they can. It's because people who code in assembler think very, very had about any feature before adding it. You'd get much the same results if people coded in a language like Brainfuck.
Any application benefits from skepticism about features, whatever it is coded in.
Now, if you think about what Google is trying to do with Chrome, launching a separate process for each tab makes sense; it is a legitimate use of resources. Each tab is, presumably, hosting a different application. You don't want them running in the same address space, anymore than you want traditional applications running in unprotected memory by cooperative multitasking. Yes, it takes more resources to do this, but I've heard much the same complaint about virtual memory and process preemption.
You don't want some random site's malware to get to close to the online banking application running in a different tab, so you've got to take steps. If you're coding was perfect, those steps probably would work pretty well, but running the online apps in different processes is a legitimate use of resources. You can try to protect pages from each other, manage resources such as processor time between them, but eventually you're coming very close to making the browser an operating system in itself.
In fact, for the purposes of Chrome, the browser is an operating system, or at least a layer in the whole operating system that hosts applications. By taking advantage of the underlying operating system's facilities, the browser doesn't reinvent the wheel, but it comes at a cost.
There isn't a universally right or wrong answer to how to architect something like this. When considered as a hypertext viewer, this kind of architecture is wasteful and bloated. When considered as facility to participate in multiple distributed processing applications, this kind of architecture isn't bloated. It consumes more resources, but to achieve an important goal.
Re:Standards (Score:1, Informative)
Chrome uses an outdated version of Webkit: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/0.2.151.0 Safari/525.19. This is why the carpet bombing exploit [raffon.net] works in Chrome.
Safari 4.0pre has newer Webkit (and passes ACID3): Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/526.11 (KHTML, like Gecko) Version/4.0dp1 Safari/526.12.2
Re:Firefox Damage Control Is More Than Enough (Score:3, Informative)
WebKit is a parser and layout engine. It will call underneath to code that actually renders text onto the canvas, much like Gecko calls Cairo.
Re:Firefox Damage Control Is More Than Enough (Score:2, Informative)
Almost certainly Firefox's; Chrome directly uses the Mozilla NSAPI code, and it doesn't do ActiveX.
um, do you mean that Chrome doesn't use ActiveX? Open up about:plugins in chrome and look at what the first thing in the list is, that it installed on its own by default. I am not saying you are wrong that they use firefox's code, just that they do use ActiveX.
Re:I don't get it. (Score:3, Informative)
That has nothing to do with what he's asking. His question is: For those users who can AFFORD to open dozens of tabs, why should the OS get sluggish if you're only using 10% of total available RAM?
Re:Firefox Damage Control Is More Than Enough (Score:3, Informative)
Okay, I've investigated further.
Above, I was depending on Google's own statement [google.com] that "Google Chrome, Mozilla Firefox, Apple Safari, and others do not support ActiveX. Instead, these browsers make use of the Netscape Plugin Application Programming Interface (NPAPI)."
Looking around, further, the activex shim is explicitly described as [chromium.org] "A shim for running some Active-X controls in Chromium."
Poking around in the source tarball in the activex_shim directory, it looks like they're working on a general support-ActiveX-through-NPAPI plugin; both Firefox and Opera are mentioned in the README. This NPAPI plugin is presumably not yet able to support all ActiveX controls.