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 431608
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: Real tests
by lemur2 on Sat 26th Jun 2010 14:51 UTC in reply to "RE[5]: Real tests"
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[8]: Real tests
by looncraz on Sat 26th Jun 2010 17:02 in reply to "RE[7]: Real tests"
looncraz Member since:

Exactly what I wanted say, dear friend!

I think Mozilla may be going the wrong route.

They should have:

*nix[+haiku] / Windows / mozui.dll / mozd2d.dll
OR / mozsoftrend.dll

Their products use MozUI, and MozUI uses whatever works for the platform, withe ability to fall back to a software rendering solution whenevr needed.

All my little cross-platform apps use LoonCAFE, which abstracts pretty much everything that isn't pure c/++. Well, that is the goal... God I need to win the lottery...

--The loon

Reply Parent Score: 2

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[8]: Real tests
by lemur2 on Tue 29th Jun 2010 01:54 in reply to "RE[7]: Real tests"
lemur2 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.... "

I don't know if Microsoft have resolved it by now, but as I understood it after XP OpenGL on Windows was designed to be implemented on top of DirectX. This double-API layering (conversion of OpenGL calls into DirectX equivalents, and then passing them on to DirectX) effectively killed the post-XP performance of OpenGL on Windows compared to what it was on XP, and compared to what it is on other platforms. AFAIK, because of this move by Microsoft, there is still a subset of Windows machines that have absolutely abysmal OpenGL performance.

Because of this period of abysmal performance of OpenGL on Windows, many developers were convinced to develop for DirectX only. They may now possibly regret that decision, because it now means their products are Windows-only products, and cannot easily be ported to other platforms via re-compilation. This is beacuse platforms such as smartbooks, smartphones, tablets and pads typically lack any support for the Direct-anything set of APIs.

Edited 2010-06-29 01:56 UTC

Reply Parent Score: 1

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