Slashdot Mirror
IE9 Team Says "Our GPU Acceleration Is Better Than Yours"
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."
...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 :)
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.
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.
Help stamp out iliturcy.
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.
Show me on the doll where his noodly appendage touched you.