IE9 Team Says "Our GPU Acceleration Is Better Than Yours" 360
An anonymous reader writes "Over on the IE blog Microsoft's Ted Johnson writes, 'With IE9, developers have a fully-hardware accelerated display pipeline that runs from their markup to the screen. Based on their blog posts, the hardware-accelerated implementations of other browsers generally accelerate one phase or the other, but not yet both. Delivering full hardware acceleration, on by default, is an architectural undertaking. When there is a desire to run across multiple platforms, developers introduce abstraction layers and inevitably make tradeoffs which ultimately impact performance and reduce the ability of a browser to achieve 'native' performance. Getting the full value of the GPU is extremely challenging and writing to intermediate layers and libraries instead of an operating system's native support makes it even harder. Windows' DirectX long legacy of powering of the most intensive 3D games has made DirectX the highest performance GPU-based rendering system available.' Some Mozillians hit back in the comments to the IE Blog post and others have written blog posts of their own. PC Mag's Michael Muchmore seems to conclude that IE9 and Firefox 4 are more or less the same (despite the title of his article) while Chrome currently lags behind."
The best part about in-browser GPU acceleration... (Score:5, Interesting)
...is that thanks to the lack of an IOMMU on consumer x86 computers, JavaScript exploits in the browser can now give you access to all the computer's memory, and along with it, ring 0. I can't wait to see the first whitepaper on the subject :)
Re:What good is... (Score:1, Interesting)
Last I checked, Firefox's hardware acceleration is Windows-only too, so you're not gaining anything by using Firefox, either. (Oops, I'm wrong. Turns out it's just only "activated" for Windows Vista/7 [mozilla.org], and from what I can tell, "activated" is code for "built into the provided binaries," meaning you can't try it on other platforms without compiling Firefox yourself. Which, if you haven't tried it, is retardedly hard to do.)
Plus, with the new beta (4.0 beta 5), I had to turn Firefox's hardware acceleration off because it broke font rendering. Somehow I find displaying readable text to be more important than being able to display unreadable crap REALLY REALLY FAST!
I tried to submit something through the feedback thing, but as far as I can tell, things written there go nowhere, so who knows.
Re:What good is... (Score:2, Interesting)
Playing devil's advocate here. Adobe Shockwave is pretty much Winhoze specific and games written in it are very much alive and kicking.
In fact the only reason it is still alive as a runtime is because it is hardware accelerated. So there is a niche for that which means that there will be a niche for a Windoze only browser with hardware accel.
Re:Pointless battles (Score:2, Interesting)
Speaking of Firefox bugs that should've been fixed ages ago but never have. There's my all time favorite bug: Bug 105843 - Cache lost if Mozilla crashes (https://bugzilla.mozilla.org/show_bug.cgi?id=105843 [mozilla.org]). This bug basically says it all it is 9 YEARS old. So for well probably since Firefox has been made it has never cached anything right. Never set that browser cache too high one crash and it's all gone. I can't even begin to imagine how much extra data Firefox needs to download over other browsers. It's also why Firefox seems to chug so much after it crashes when you have 20 tabs open and the thing crashes.
Like the OP I find it really ridiculous they can't get the basics right yet we seem to get GPU accelration, it's just pathetic.
Re:Pointless battles (Score:3, Interesting)
I can't say any of those bugs have ever bothered me. The upload progress thing only slightly. If I can choose between a faster Firefox and proper upload progress I'd rather choose the former. Your definition of useless battles isn't the same as everyone's.
Re:Pointless battles (Score:5, Interesting)
A 728x90 GIF banner would use 250 KB per frame and at about 30-100 frames per banner, you're looking at 10-30 MB per banner. How many GIF's are in an average page? Lots. How many GIFs are in lots of tabs? Lots. How many bug reports and complaints are on the 'net about Firefox using a lot of memory? Lots.
It *is* a bug that affects very few people *critically* (crashes) but it is one that makes the browser generally look bad in reviews and other tests, due to the memory usage.
The problem that's brought up every time is that it's impossible to know how big a GIF file is until it's fully downloaded, so they say they have to decode each frame and keep it cached in memory. However, a simple solution would be to keep both the compressed and uncompressed frames in memory and when a memory threshold is reached, dump the uncompressed frames and switch to real time decoding.
This way, for example, with a 32 MB threshold, small GIFs like banners would be fully decoded and kept in memory but with larger gifs, once the 32 MB limit is reached, the decompressed frames are dropped and only the compressed frames would be kept in memory, so Firefox would not crash.
Would have done it myself but I'm not good at the language used by Firefox developers.
Re:The best part about in-browser GPU acceleration (Score:3, Interesting)
AMD x86_64 processors have an IOMMU. Intel's first x86_64 processors didn't but I don't know if this is still the case. IOMMUs are also important if you are running virtual machine software that allows some VMs access to physical hardware -- Xen lets you do this, for instance.
...and it might actually matter when you can actually find a motherboard with a chipset that also supports the IOMMU on the CPU. At the moment, that means an X58 chipset (socket 1366) for Intel, and for AMD, you're pretty much out of luck.
Re:Let's just forget about the big bottleneck here (Score:3, Interesting)
When viewing scaled video, it's a huge factor. And when using web applications (as opposed to reading the news) it's a significant factor. Oh, and when scrolling, not like anyone ever does that with webpages.
And we're not talking tenths of a millisecond here. If each scroll operation takes you 200ms (easy to run into without hardware acceleration on some sites out there that are sticking video or large translucent images over fixed-position backgrounds), you just lose.
Oh God (Score:3, Interesting)
I wish I could introduce you to the hell that is HP's partner portal, their Learning Center, the portal for support. It's a carnival of the obscene. As someone who understands web design I have to hope there's a special level of hell devoted to eternally tormenting these web developers.
Not only do these sites require specific versions of IE, but then you come to a certain point where they don't even work with those, so you have to migrate the session to other browsers through trial and error until you find the one that works with it. It's sick. It's like an online skill test that requires four nines of web proficiency in order to download a freaking driver update or read the product alerts.
In a perfect world some auditor would have these web developers separated from their skin slowly, under a saltwater and lemon juice shower while rats ate their organs, with a blaring Phil Collins soundtrack.
Re:Pointless battles (Score:3, Interesting)
I can blame Firefox as much as I want when the same 8 MB grayscale GIF that crashes Firefox (>2 GB memory) makes Chrome use only 50 MB and Internet Explorer only 900 MB of memory.
Re:Oh God (Score:2, Interesting)
I noticed this on the website:
Does it matter which browser I use? Does it have to be a certain version?
For the best experience, we recommend Mozilla Firefox 1.07 and above, Microsoft Internet Explorer 6.0 and above, Opera 8.0 and above or Apple Safari 1.1 and above. http://h30187.www3.hp.com/page/p/title/faq [hp.com]
That faq looks equally bad in IE8 and Chrome. Take a look at the source, it's a mess.
Re:Pointless battles (Score:5, Interesting)
neither you nor I fixed those bugs, either.
Have you tried fixing any Mozilla bugs? I have and it's a royal pain in the ass. You first post your patch to the bug itself, which is simple enough. Then the main cabal of developers critique your patch, and if it doesn't exactly conform in every possible way to what they would have coded themselves, they will reject it with little, if any, explanation. After you finally get an explanation out of someone, you can continue to submit changes to see if any will appease them. Of course, you will have accidentally violated a minor style guideline, but this won't be pointed out to you until you've submitted changes for their other critiques six times. After you've fixed that issue, they'll think of some other hoop that you'll have to jump through even though the patch fixes all aspects of the defect at this point. After another 16 edits of the three line patch that doesn't have any security implications and doesn't change any portion of the API, they'll ask you for a unit test that wouldn't test anything but the API for which they already have unit tests.
I'm all for being careful and making a stable, secure product, but I expect people to not be completely retarded about the process of writing software. Not even the system that delivers EAMs has a process this annoying for fixing trivial defects.
And *that* is why Mozilla defects don't get fixed for years.