Linked by Kroc Camen on Sat 26th Jun 2010 10:48 UTC
Internet Explorer Microsoft have released IE9 Platform Preview 3, an application that gives developers access to the IE9 rendering engine (it's not a full browser). In this update they have added hardware accelerated HTML5 Video, Canvas, Fonts (using WOFF) and big improvements in JavaScript with ES5, DOM Traversal, L2 and L3 events and 83/100 Acid3 score. It sits between Firefox and Chrome 6 on JavaScript speed, but outperforms every browser in real tests.
Thread beginning with comment 431603
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: Real tests
by dpJudas on Sat 26th Jun 2010 14:26 UTC in reply to "RE[4]: Real tests"
Member since:

What a silly conspiracy theory.

The hyped hardware acceleration in IE9 is nothing more than IE changing from using the GDI scanline renderer to the Direct2D renderer they added in Windows 7. This is a public API and so any competitor can also use this for their rendering if they so desire.

Just like any other modern windowing system, Windows Vista and Windows 7 stores each window in a texture on the GPU, regardless of what technology you use for the rendering. The windowing system then offers a series of different technologies to fill that texture with contents. In Windows those are GDI, DirectDraw, Direct3D, Direct2D and OpenGL.

What we are talking about here is simply a new interface that is more compatible with the way a modern GPU works. The original GDI graphics API makes some assumptions about the graphics card that isn't true anymore and therefore virtually everything in GDI has been running in software. Microsoft gave up on accelerating it and instead wrote Direct2D and now are bragging how fast IE gets if they use that instead.

If you wonder what is wrong with GDI, then its small subtle things like being able to render directly to the screen (which doesn't make sense when your display window manager does that) and the entire way bitmaps were designed.

Reply Parent Score: 8

RE[6]: Real tests
by lemur2 on Sat 26th Jun 2010 14:51 in reply to "RE[5]: Real tests"
lemur2 Member since:

The hyped hardware acceleration in IE9 is nothing more than IE changing from using the GDI scanline renderer to the Direct2D renderer they added in Windows 7. This is a public API and so any competitor can also use this for their rendering if they so desire.

Direct2D is Windows-only. If one writes an application to use Direct2D, then it is forever doomed to be a Windows-only application.

All of IE9's competition (that is, other competitive browsers, to whit: Opera, Firefox, Chrome and Safari) are all cross-platform applications. They all use APIs that are not going to doom them into being Windows-only applications.

OpenGL on Windows is crippleware. OpenGL or Xrender would be the APIs that other browsers would use, and not Direct2D. Firefox uses Cairo, for example, and hardware acceleration for Cairo is being done via OpenGL. This will work well everywhere except Windows.

The current plan to hardware accelerate Gecko and Firefox is to use OpenGL. This seems like a good starting point because it's supported (to varying degrees) on all the platforms we care about (including mobile platforms, in the form of OpenGL ES). (Note that it will be necessary to support both software and hardware render paths, because not all computers will be capable of GPU acceleration.)

Follow-on work for this might include making a Direct3D/Direct2D backend, especially if it's found that OpenGL stability/availability on Windows isn't sufficient.

So applications like Firefox for Windows have to write functionality like hardware acceleration twice. They have to write it once for most platforms using Xrender or OpenGL, and then they have to write it again for Direct2D, just for Windows:

It will happen, but it will take a bit longer. This is just another way for Microsoft to make other teams look slower, for Microsoft to write its applications to be Windows-only, and in general to create a software corpus which is harder to make cross-platform than it needs to be if Microsoft had stuck with standard APIs.

Edited 2010-06-26 15:09 UTC

Reply Parent Score: -1

RE[7]: Real tests
by Tuishimi on Sat 26th Jun 2010 16:34 in reply to "RE[6]: Real tests"
Tuishimi Member since:

Then you design YOUR UI with wrapper code that is able to reference two different underlying libraries and rely on build scripts to know which to compile into the application. There are ways to do this on the developers' end and once the work is done it's done.

Hopefully you will have designed it with the future in mind and the ability to add to the API when needed and not to have to rewrite large chunks as things change underneath.

Reply Parent Score: 4

RE[7]: Real tests
by Moochman on Sat 26th Jun 2010 17:15 in reply to "RE[6]: Real tests"
Moochman Member since:

OpenGL on Windows is crippleware.

Where do you get that from? There are plenty of Windows games and 3D software packages that run on OpenGL, and I've never heard of any issues, at least not any that were actual Windows issues and not just related to the drivers....

Edited 2010-06-26 17:16 UTC

Reply Parent Score: 6

RE[7]: Real tests
by siride on Sat 26th Jun 2010 17:52 in reply to "RE[6]: Real tests"
siride Member since:

I'm sorry, but what the hell *are* you ranting about? You seem to be upset that Microsoft has APIs at all, as if this is some cardinal sin. Yes, it's true that if you use an API to write your program, you will be stuck with that API if you are not careful when constructing your program. This is not news and it's just as true on Linux, OS X, BeOS, OpenBSD, etc. as it is on Windows. If you use Xlib, then you will be stuck with Xlib. Who cares?

And also, why should MS write all of their programs to run on every GD operating system out there? It's not in their interest and honestly, it's a waste of time.

Reply Parent Score: 6