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.
Microsoft’s use of language has improved too. Microsoft reiterate their goal of “same markup” working across browsers which is a fresh break from Apple’s one-browser view of the web. Their tests work in other browsers rather than blocking them.
The changes are almost too numerous to list, Microsoft have added more stuff than you can shake a stick at. The main things to note are:
- Canvas
-
Canvas is a tag invented initially by Apple for use in their Dashboard feature in Mac OS X Tiger, it allows a developer to draw arbitrary graphics on the page and opens the gates for games, visualisations and new kinds of interactive effects. Microsoft’s implementation is hardware accelerated (when the hardware is present) and outperforms every other browser at this time by an order of magnitude. Microsoft only have to support Windows Vista and Windows 7 unlike other browser vendors and have thus been able to focus on tight Windows integration with DirectX.
Because some browsers run on many different operating systems, there can be a tendency to use a “least common denominator†approach to implementing HTML5. By using more of the underlying operating system, and taking advantage of the power of the whole PC, IE9 enables developers to do more with HTML5. Running through Windows, instead of just on Windows, makes a big difference; the web runs more like a native application.
- Video
-
HTML5 video has become a buzz of hyper-activity following a string of high profile clashes between vendors. Adobe’s Flash Player has continued to be a sore spot and Apple have vehemently refused anything Flash-related to go within a league of their precious iDevices. This has caused many to sound the death knell for Flash and Flash advocates to then fight back likewise. A number of large mainstream video sites offered HTML5 demos and Google purchased On2 for $120M before releasing VP8 as an open, royalty free codec, stirring up the pot even more.
HTML5 video is not without its problems. It lacks basic features present in Flash, the implementations in browsers are spotty and flawed and the debate on codecs has raged with still no one codec to rule them all.
The HTML5 video specification doesn’t specify any codec to be used, and thus it’s fair game for the vendors to decide. Mozilla and Opera have categorically stood on the side of freedom of use by supporting only free and open codecs where Apple and Microsoft have both opted for H.264, a patent laden codec managed by the MPEG-LA who Apple and Microsoft are both patent holders therein. Microsoft relented somewhat following the announcement that Google with be switching YouTube to VP8 and this was already underway, by allowing IE9 to use the VP8 codec if the user installed it themselves.
- Web Fonts
-
Microsoft have supported downloadable fonts in web pages since IE4 using their own EOT format. After an initial push to put this forward for standardisation in 2008, Microsoft [surprisingly] got behind the WOFF format instead and joint with Opera and Mozilla came to an agreement. The WOFF format is an open, compressed font-type designed for delivering fonts over the web and meets the requirements of type foundaries who are worried about rampant piracy. The addition of WOFF to IE9 will seal WOFF as the standard format for font embedding on the web. Currently, browsers support a mix of WOFF, TTF, OTF, EOT and SVG fonts.
Through the use of DirectWrite, Microsoft’s hardware accelerated text API, web fonts are rendered with high quality typography and anti-aliasing.
- ES5
-
ECMAScript is the standardisation effort to define JavaScript given that JavaScript is itself a Netscape invention and trademark of
SunOracle and there are other incompatible implementations such as Microsoft’s own JScript.As context, the industry standard that defines the JavaScript language is ECMA-262: ECMAScript Language Specification developed and published by Ecma International. Prior to last year, it had been a decade since the introduction of the Third Edition of ECMA-262 in December 1999. In December 2009 Ecma approved the Fifth Edition of ECMA-262 as the successor to the Third Edition (a Fourth Edition was never published), and last year we debuted elements of ECMAscript 5 (ES5) support when we added native JSON support in IE8. Beyond JSON, though, ES5 standardizes many significant enhancements to the JavaScript language.
Read Microsoft’s article for the skinny on new additions, including new Array methods, an enhanced Object Model and changes to IE’s script parsing to allow “Same script, Same Markup” across browsers.
For a full list of changes and improvements see the Internet Explorer Platform Preview Guide for Developers.
The amount of work presented here (and the manner in which it is presented) shows a firm commitment by Microsoft to participate in the web in a way that makes developer’s lives easier and allows for all new innovations in the native web. (H.264 aside, mind). As mentioned before, this is in stark contrast to Apple, and the Microsoft of the IE6 years. There’s still a long time to go before IE9 is actually released and still many contentious areas of standards (like WebGL, which goes against DirectX and other areas of Microsoft’s business interests).
Are there any real tests to back this up? Like startup times, loading and displaying complex pages, working with some heavy websites. I did some searching and only found synthetic tests, showing that IE9 has finally caught up with other browsers in JavaScript speed and that it is very fast when drawing scaled bitmaps using the GPU.
Edited 2010-06-26 11:42 UTC
Microsoft are focusing on more than just raw JS execution speed as most of the browser’s time is spent outside JS doing DOM and layout. In this respect, IE9 is faster as everything is hardware accelerated right down to the text.
IE9 is neither released, nor finished but it shows an approach that is ahead of the other vendors. I doubt it will last though, hardware acceleration is planned to arrive with the other browsers who will still ship first.
Why should one need hardware acceleration in order to display text and pictures, which the current Web essentially is from a display point of view ? I know that current code is unoptimized, but I didn’t know that it was *that* bad…
Edited 2010-06-26 13:22 UTC
It’s not about _need_, it’s about availability. If a GPU is there and it’s “only 14x faster†than the CPU, then why not use it, for everything; even text—which is a whole lot more taxing than most give it credit.
Why not simply use the GPU to accelerate the whole desktop, even text?
This way, all applications will equally benefit from accelerated performance, not just the browser …
Oh, wait a minute, perhaps I see. Even your commercial competitor’s application would benefit if you used the GPU to accelerate the whole desktop.
Not a problem for open source OSes, however …
Yes, that’s called Aero and Windows Presentation Framework.
Seriously, even after all these anti-trust sanctions, people still think MS is using hidden APIs for non-core OS functionality. The APIs are openly documented, they – legally – cannot use hidden ones.
Acceleration APIs are not hidden, and I made no claim that they were.
The problem is that Windows APIs are unique to Windows, and they don’t use a common API (such as something similar to Canvas) that could accelerate all applications.
Therefore, each cross-platform application on Windows is required to write its own hardware-acceleration for rendering built in to the application, rather than it being available as a system-wide library to call.
If there were a system-wide Canvas library, for example, then every application could use it to get the benefit of hardware-accelerated rendering.
Instead, Microsoft simply won’t implement that as a system-wide library, and as a consequence you get performance discrepancies between applications such as this:
http://www.globalnerdy.com/2010/06/24/ie9-s-hardware-accelerated-ca…
That video makes Google Chrome look glacial compared to IE9 preview, but really, all it shows is the difference between hardware-accelerated Canvas draw versus software-rendered Canvas draw. The difference is due to the fact that hardware-accelerated Canvas drawing is simply not a system library on Windows, and that functionality must be built in to each application separately.
Edited 2010-06-26 14:37 UTC
Why doesn’t Microsoft just write the browser for them? Seriously? A system-wide canvas library? What on earth?
Microsoft does the best that they could, Direct2D is a relatively simple API (though still a COM API, but ugh), but simple nonetheless.
HW Accelerated canvas drawing is simply a consequence of the entire renderer being written in Direct2D.
Direct2D is Windows-only. It is useless for cross-platform applications.
If Microsoft won’t provide a Canvas library, then how about at least a respectable OpenGL API? What would be the reason for horrible openGL performance on Windows, too hard, or too much like actual competition?
Uh, because it’s not up to Microsoft to make. OpenGL implementation is wholly up to the IHV.
That’s kinda the weakness of OpenGL, a sometimes varying mashup of different vendor extensions and what could be dodgy implementations.
DirectX simply outclasses OpenGL in ease of use, it’s the lesser of two evils. One uses COM and the other tries to shoehorn an object based API into a C-based abomination.
There is no sense of a way forward with OpenGL, it’s more or less following the lead of DirectX10 and DirectX11
OpenGL has an overwhelming benefit in that it is a cross-platform API.
If one wants a “code-once, deploy everywhere” approach, then OpenGL is the premier choice of API. Unlike DirectX, using an OpenGL API will allow you to code once for deployment on desktops and one mobile devices such as phones, smartbooks, tablets and pads.
One could argue that Microsoft focussing its current development on Windows-only APIs such as DirectX, which effectively tie any code using that API to deployment on Windows systems only, is the very reason why Microsoft has only a 27% mindshare amongst phone and mobile developers.
http://www.theregister.co.uk/2010/06/27/android_iphone/
Edited 2010-06-28 03:15 UTC
Alright, you stopped making sense a while ago. I point out the inherent weaknesses in OpenGL and you just reiterate your useless point about it being cross platform.
That’s nice, but it’s wholly besides the point that I was making, which is that OpenGL has not, and will not be adopted by Microsoft for reasons beyond ideology.
It’s a slow moving standard with a lack of direction, which takes development cues from DirectX.
Also, I really do not see what Microsoft’s statistics for Windows Mobile 6 have to do with OpenGL adoption or a lack thereof.
The mobile industry moves at a breakneck pace, and there have been various Kings of that sector. To imply that their success is tied to an irrelevant strategic move that the average consumer both doesn’t know, or give a damn about, is simply absofuckinglutely crazy.
It’s crazy. You mash up all the negative Microsoft press you can find, and somehow try to string them together and draw one hell of a conclusion.
Direct2D, hands down, is easier to use than almost everything for hardware accelerated 2D drawing. Open does not mean better.
In fact, I see a lot of chest thumping by the open standards, open source, interoperability crowd, but I think it’d be best for them to try to maybe outclass the status quo before seeking to change it.
Direct 2D ? Easy ? This guy does not seem to think so…
http://braid-game.com/news/?p=466
Random guy ranting on a blog, yep that sure ends this debate.
It’s a ridiculous comparison. Direct2D comes with all the bells and whistles, and basing your comparison off of a sample which doesn’t use nearly as many features as you’re boilerplating, is intellectually dishonest.
Direct2D is more general purpose than DirectX, and when you do something even remotely complex in Direct2D, trying to reproduce them in DirectX or in OpenGL is hell.
That entire post was orchestrated to pick the worst possible scenario for Direct2D, and shine a spotlight on it. Direct2D’s functionality is not just restricted to the basics shown there, and as any DirectX programmer will tell you, the strength of DirectX is in your abilities to be deterministic in managing your GPU resources. Something he seems to rant about there, which is confusing.
He goes into sidestepping the issue of resource management by which he states he could do insert contrived 3d trick here, which completely defeats the purpose. Direct2D is designed to be easy for everyone, not easy for a 3D programmer who could set a z-plane to zero and manipulate items on screen in a manner in which he’s familiar with.
Anyhow, he gets pretty thoroughly destroyed in the comments by anyone who has any kind of experience with programming with COM.
Regardles about your views on OpenGL, it remains the one API which one can code to so that one can easily port it to multiple platforms. Direct2D simply does not provide this capability, regardless of your ideology, because the majority of platforms provide no Direct2D API.
This is the plain and simple truth. Ranting about what Microsoft will or will not do won’t change that fact. Nor will claiming superlative benefits for Direct2D change the fact that more platforms support OpenGL. It won’t change the fact that when you walk into a games store, Xbox/PC is the one platform that uses Direct-anything, nor will it change the fact that when you look at a range of smartphones, smartbooks, tablets and internet “pads”, the vast majority of them support OpenGL but not Direct2D.
Deal with it.
That just calls into greater question the necessity for such a thing. With DirectX being the de-facto API (due to both the ubiquity of Windows, the rapidly evolving feature set (to meet an even more rapidly evolving graphics scene), and the braindeadness of the OpenGL API and functional deficiencies), there really doesn’t seem to be such a need for OpenGL.
The PS3 has it, but it’s in name only, internally it uses Sony’s own stuff, and really the only room for even remote code sharing is between the PC and a gaming console. Mobile device form factors are different enough that not much technology and assets can be shared.
But where is the line drawn? Do you criticize input APIs from not being universal? Or windowing APIs? Why not just have one operating system if you’re striving for uniform programming interfaces between them?
Is it fair for me as a Windows user to complain to the absolute terrible implementation that GTK has on Windows? And how comparatively, Linux leaves it in the dust?
This is like saying that because Microsoft deliberately crippled OpenGL on Windows, OpenGL is crippled, and cannot be considered as the standard. Pfft.
Many would beg to differ (There are, after all, more CPUs that don’t run Windows than CPUs that do. The desktop is not the be all and end all of computing.) Rather, the objective perspective on it would conclude that OpenGL is the standard and Windows is abysmal at implementing it.
AFAIK, Microsoft one day approached the OSS Blender project, asking how Microsoft could help to improve the terrible performance of Blender on Windows (I think Microsoft were wanting to convince the Blender project to write a DirectX layer for Blender). I think the answer that Microsoft got from the Blender developers was simply to fix OpenGL performance on Windows.
http://blenderartists.org/forum/showthread.php?t=183858
http://forums.nvidia.com/index.php?showtopic=97244
HINT: None of this is a failing of OpenGL.
Edited 2010-06-29 06:20 UTC
Alright, it’s time to address this. I’ve let you run with it because others have addressed it, and because mainly I wanted to reply with more than “no it’s not” as opposed to you, who have only said “yes it is” when it comes to credible sources.
First off, here’s the OpenGL WG themselves seemingly praising the changes in Vista (and 7) and how they affect OpenGL perf:
http://www.opengl.org/pipeline/article/vol003_9/
Second off, knowing a bit of how OpenGL is architected will help you understand why any performance hit is not the fault of Microsoft.
OpenGL implements a lot of the runtime in ICDs (as opposed to DX which has one runtime, then a kernel counterpart to talk to the hardware)
In Vista (and 7) OpenGL can either use the Default ICD, or an ICD provided by your driver vendor.
The default ICD uses OpenGL 1.4 and is layered on top of DirectX, the others do not and the performance of them is dependent of their respective implementations.
You cite a strength of OpenGL in it’s cross platform capabilities. A lot of that strength goes away, when it’s not ubiquitous on desktops, consoles, and where it does have some ground (mobile phones) it has a form factor which differs so wildly that actually sharing large amount of rendering code is not practical.
Sigh….
As people keep explaining Ogl is a *3d* api therefore you would need a library on top of it to use it. Also as a 3d api it is notorious for being dreadfully inaccurate when it comes to things like text rendering (see the problems the Qt guys have had implementing an Ogl backend).
If you’re really looking for a cross platform 2d acceleration framework you need to look at openVG, but I don’t think it has much mainstream traction.
There is a system-wide library to call, it’s just not the same one that’s available on Mac or on Linux, each of which have their own (multiple, in fact) system-wide libraries to call.
It’s really unclear what you are asking for that isn’t already present in Windows, and what you think Windows lacks that is somehow magically present elsewhere. Cross-platform apps that use normal widgets can use cross-platform toolkits like Qt… which already offers native hardware acceleration on a number of platforms. Or they can just use OpenGL directly…..
The reason Firefox and apps written in other toolkits don’t already support hardware-accelerated rendering is as I understand it because they use low-level, CPU-based (not GPU-based) calls to figure out how to render stuff. There’s really not a whole lot that can be done without some sort of rewrite.
Edited 2010-06-26 17:09 UTC
OpenGL is terrible on Windows. Utterly shocking performance.
Direct2D is Windows-only, and it is useless for any cross-platform applications.
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.
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.
https://wiki.mozilla.org/Platform/GFX/HardwareAcceleration
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:
http://www.basschouten.com/blog1.php/2010/03/02/presenting-direct2d…
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
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.
Exactly what I wanted say, dear friend!
I think Mozilla may be going the wrong route.
They should have:
*nix[+haiku] / Windows
libmozui.so / mozui.dll
libmozOGL.so / mozd2d.dll
OR
libmozsoftrend.so / 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
“God I need to win the lottery…”
😀
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
http://www.astahost.com/info.php/microsoft-cripple-opengl-3d-graphi…
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
http://social.technet.microsoft.com/Forums/en-US/w7itproappcompat/t…
Hmmm. Looks like it might still be an issue with Windows 7.
I’ve worked a little bit with the internals of Direct3D/WDDM. The IHV path for writing an OpenGL driver has not become worse between XP and Vista, as far as I can tell.
The architecture isn’t much different for writing either kind of driver, it’s just that the OpenGL driver is some more work for an IHV since they have to provide more of the user-mode ‘runtime’ parts of the library.
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.
Windows comes dangerously close. At least on Windows7 GDI is more hardware accelerated than before, but not all the way. There is a real tradeoff between HW accelerating such an old API, and maintaining a decent memory footprint.
However, just the API has landed to do this on Windows Vista and Windows 7. It’s called Direct2D.
If I remember reading an article by a Microsoft developer – one of the questions I asked was regarding whether Microsoft could/would port GDI to Direct2D/DirectWrite so that GDI ran on top and merely relayed GDI calls through to Direct2D/DirectWrite. The reasoning he provided pretty much came down to two reasons; firstly they had limited time and would have loved to do it. Secondly the other problem is that it would have been very complex and very messy when one considers all the possibly variables one has to take into account.
I hope that with Windows 8 that full Direct2D and DirectWrite acceleration will come to the desktop but I have a feeling that that the grandparent (lemur2) to this thread is simply grasping at straws to justify his hate of Microsoft.
Sheesh! Direct2D is Windows-only. OpenGL is crippled on Windows, compared to the exact same hardware for other platforms. Of the top 5 browsers, IE, Firefox, Chrome, Safari and Opera, all except IE are cross-platform, and therefore only IE can use Direct2D.
That is not “hate”, those are all straightforward facts.
OpenGL on Windows is not crippled. Absent an ICD, it is hardware accelerated via Direct3D. With an ICD (which all major GPU IHVs provide), you have access to whatever extensions the hardware vendor supports.
Firefox nightlies currently use Direct2D and DirectWrite for hardware acceleration on Windows. Other 3rd-party applications may do the same, or use OpenGL. The OpenGL backend would take longer to implement because you don’t have similarly focused APIs in OpenGL. You must build it yourself, whatever the platform, or rely on some toolkit vendor whose already done that work. Alternatively, you could build a framework that wraps the similar native APIs of each supported platform (assuming such exist).
Sheesh! Direct2D is Windows-only. OpenGL is crippled on Windows, compared to the exact same hardware for other platforms. Of the top 5 browsers, IE, Firefox, Chrome, Safari and Opera, all except IE are cross-platform, and therefore only IE can use Direct2D.
That is not “hate”, those are all straightforward facts. [/q]
Except that OpenGL is much harder to implement, and implement correctly. It is much less man hours of work to implement a Direct2D renderer. I know because prior to IE9 announcing GPU acceleration, I was working on a Direct2D cairo backend for just this purpose.
That aside though, I think people get too caught up in this cross platform idea, to the point where they take the focus off of the quality on each individual platform.
An example being how horrible Firefox on OSX was up until a few years. Sure, sharing technology is fine, but don’t use it as an excuse to be lazy.
If Firefox can do it and achieve respectable performance in the little time it’s had to implement Direct2D, others can certainly do it as well. You raising a stink about it is kinda muted by their great progress in this respect.
Errrrm. Please explain why the Windows versions of cross-platform apps such as VLC and SMPlayer can use Direct3D as video output method. And then explain why the Windows version of other browsers couldn’t use Direct2D as graphics output method.
Only on Windows. Look up “conditional compilation” one day. Direct2D video output method is certainly NOT an option for applications such as VLC and SMPlayer on platforms other than Windows.
They could, but they would have to re-write their whole graphics output method, just for Windows. Mozilla has done this effort, but other vendors may or may not choose to, depending on the set of platforms they are targetting, and their resources.
They certainly won’t use Direct2D as the ONLY graphics output method, because doing that would constrain their application to Windows only.
Sure, but I never claimed that.
Your original claim was that they can’t use Direct2D in a cross-platform app. That claim is false. That is all.
No, my claim was that if your aim is to write a cross-platform application, as is certainly the case with Firefox, Opera, Chrome and Safari, then the only viable option you have to write it just once and then relatively painlessly port it to all your target platforms is to use OpenGL.
This is what the authors of cross-platform browsers (that is to say, browsers other than IE) actually do.
Some of them can afford to write the graphics layer twice, and so in addition to using the OpenGL API they also provide a Direct2D-enabled version for Windows only (for example in Firefox, a Direct2D option is provided in the Windows version, but it is not the default). That fact does not impact my original claim in any way.
Edited 2010-06-29 01:19 UTC
Except that WebKit and Gecko share the same underlying Cairo underpinnings. Write the Direct2D backend once, and share the code together.
This is what contributing to those projects is all about isn’t it?
OpenGL has a long way to go before being suitable for hardware accelerated rendering, especially getting text rendering fidelity to be in the same ballpark as DirectWrite, or being as easy to use (therefore as easy to debug and maintain) as Direct2D.
OpenGL is simply outclassed. Plain and simple.
Besides, OpenGL would be of limited use on OSX where they’ve rolled their own (superior) hw accelerated rendering apis. Trying to shoe horn a 3D API into doing 2D drawing makes no sense at all.
I really don’t see the big deal for a Windows-only Hardware accelerated API, which replaces another Windows-only API (GDI)
Except that the OpenGL hardware acceleration for cairo is already underway.
http://www.freedesktop.org/wiki/Software/glitz
http://cairographics.org/
Old, incomplete, and probably not even maintained anymore. At least thats how it was last time I took a look at it.
If Direct2D is easier to maintain, cleaner, and more suitable to the paradigm to which cairo is created to address, then why is it a bad thing if someone wants to maintain a Direct2d backend? Why should GDI backends exist? Or Quartz? Or anything?
OpenGL is as ubiquitous as you claim, why should the others even exist? Isn’t this just redundancy?
Who cares if it uses Direct2D on Windows and OpenGL on other platforms? Just like no one cares that it uses GDI on Windows, or Quartz on OSX instead of just using the glitz backend everywhere.
The aim of cross platform code should really be to share code which has no “contact” with the native API of the platform. Anything else should be abstracted to a platform specific layer.
Graphics Rendering, UI Toolkits, et all fall into this category.
It’s already been pointed out that:
1) OpenGL fails when compared to Direct2D in key areas (text rendering, ease of programming and maintenance, sane api)
2) A Direct2D cairo backend would have more general applications than browsers, and the benefits would not be specific to Firefox
3) The OpenGL glitz backend is immature and ill maintained.
I’m not advocating dropping OpenGL on platforms where it makes sense (unless you can find a sane, ABI stable 2D drawing API on Linux, you have literally dozens to choose from each with varying degrees of shittyness.. ) and using more native APIs (Quartz, GDI, Direct2D) on platforms where it makes snese..
Why can’t you do the same?
The title of this thread is about “marching to the standards beat”. In spite of what many Windows supporters seem to think, the word “standard” in this context does not mean “most popular”. For software, it is reasonably well defined by Wikipedia:
http://en.wikipedia.org/wiki/Standard_%28software%29
Direct2D is the antithesis of a software standard. If you write software to the Direct2D API, you constrain that code to run only on Windows. This is lock-in, your source code is locked in to Windows, you can only ever provide your software products to Windows users, and consequently you constrain your customers to only run Windows. This is the exact opposite of interoperability.
For this reason I would never endorse something like Direct2D for use as a “standard”. Nor IE itself, for that matter.
If, however, Microsoft were to announce tomorrow that they had decided that Direct2D was able to be implemented by anyone, for any platform, on any architecture, on a royalty-free basis, regardles of any caveats about “commercial use” or whatever, and able to be licensed however the implementer chose, including royalty-free re-distribution rights for downstream recipients, and at the same time Microsoft published the full specification of the API, then it would be a differnt story.
Since it would then be interoperable, Direct2D would probably become entirely suitable as a standard graphics API under such circumstances.
Edited 2010-06-29 10:18 UTC
Seriously…. Stop taking. You are embarrassing yourself.
This entire thread you have been complaining about something that amounts to how windows is hurting cross platform vendors by having APIs available to use.
Now you are trying to conflate some argument that windows APIs are not standards compliant….
Either you think we are stupid or you are so blinded by hate fro windows that you can not see the stupid argument you are making.
I think you are just kicking up dirt and think you are going to convince people with that method of argumentation.
Sorry, this is not some political radio talk show and we are not idiot listeners. That stuff does not work on us.
Seriously, for decades, royalty-free software standards were set so that there could be a chance for developers to write one set of source code for a given application and compile it for multiple different platforms. OpenGL is one such standard, ASCII itself is such a standard at a low level, POSIX is another standard at an API level, X11 is another, ELF yet another. The software languages themselves, C, C++, Pascal, Java, etc are also written with this in mind. Such software standards with a view to interoperability was the practice for decades since computing began in earnest way back in the 1950’s, it was in fact the whole point of high-level-languages. Pertinent to this thread, royalty-free communictaions standard protocols such as TCP/IP, HTML, CSS, DOM et al, and predecessor standards such as FTP, SSH and a raft of others were also established so that different separate-but-connected computers could inter-operate.
So Microsoft comes along, decades later, and decides to try turn the whole concept on its head, and deliberately writes anti-standards exclusive to its own platform, with the express intention of preventing such cross-platform interoperability, such as Direct2D for an internal interface anti-standard to the graphics hardware, and ActiveX as an external anti-standard over the web, in an effort to establish a monopoly and force everyone to have to use their stuff, in direct defiance of antitrust laws … and all you can stutter in response when someone points it out is to tell that person to stop talking?
Really? Is that all you have got?
Wow. You make such a telling point … NOT!
BTW, you should know that your faked indignation is not at all convincing.
Edited 2010-06-29 23:48 UTC
This is seriously the stupidest argument I’ve ever seen on this site.
Think about what you’re saying here. Do you advocate getting rid of Haiku? Because, let me tell you, that OS has some “non-standardized” API’s in it. A cross platform application that runs on Haiku and hooks into it’s native APIs must therefore be misguided, huh? How about ALSA – everyone should have just stuck with OSS instead of going to a linux specific API, shouldn’t they. Or is it only Microsoft’s native APIs that you object to?
Direct2D on its own isn’t so much the problem as crippling OpenGL in conjunction with providing unique-to-Windows Direct2D. “Un-crippling” OpenGL on Windows, or allowing Direct2D to become a true standard able to be implemented and used on other platforms … either of those actions would remove the anti-trust violation represented by Direct2D as it stands now.
Haiku is in absolutely no danger of antitrust violation of any kind.
What’s stopping anyone else from implementing Direct2D right now? I assume Wine is probably working on it. And there’s certainly nothing stopping other platforms from creating an alternative 2D acceleration framework to compete with it.
Getting MS to stop hurting OpenGL is a good thing, but insisting that they can’t do any of their own code is stupid.
I have to agree with one of the earlier posters, I haven’t had any problems at all with OpenGL if I install a vendor graphics driver. Does anyone actually stick with the default MS graphics driver? I’m pretty sure that’s the only issue here – except for the fact that Intel also refuses to create a good OpenGL stack on windows.
Nah, he is just psychotic when it comes to anything and everything Microsoft. The king of stupid arguments has got to be Moulinouf, who is psychotic about everything in the world. I think they live in areas that are not well covered by mental health professionals…or they just don’t take their meds.
Edited 2010-07-01 21:57 UTC
It’s like talking to a brick wall. I give up. People like you will always see software from a fanatic point of view.
Thankfully, only the loud mouths preaching on about FOSS share this same form of mental handicap. The actual programmers behind the products which even let you put yourself on such a highstool are more sensible than you.
I applaud Firefox for being pragmatic enough to implement Direct2D.
Yeah, well. You can hardly expect Microsoft to be visionary in regard to the desktop. Even now MS is trying to figure out a way to monopolize the net, by running it “natively”. It gives a completely new depth to “my internet has crashed” :p
Okay. It’s just that when I hear about browser hardware acceleration, I see in the future Canvas-powered websites which use the GPU for stupid things, just like Flash currently does. I see laptop battery life continue to go down. I see a Vista effect where developers require ultra high power from the user’s machine because their own machine is powerful. I see users which don’t have fast 3D acceleration being penalized because they use open-source drivers or AMD’s crappy proprietary drivers, or just because their old laptop includes a crappy intel GMA chipset.
If you make the feature available, you can safely assume that people will use it. Hardware acceleration in browsers is just like composited desktops : it’s fine as long as it’s optional and people can survive without it. Sadly, the web is not a desktop, where disabling compositing will just make windows look ugly. If developers require hardware acceleration and it’s not available, the site won’t work. That’s the kind of things which I’m fearing.
Edited 2010-06-26 14:46 UTC
If we’re lucky, somebody will create a ‘Canvasblock’ extension, so we can only turn it on only when it’s needed, which, if it’s like flash, will be about 2% of the instances where it’s actually used.
–
Edited 2010-06-28 12:36 UTC
Using GPU accel isn’t straight performance win: http://blogs.gnome.org/otte/2010/06/26/fun-with-benchmarks/
Maybe that might explain why Microsoft noted that there are some things that 2D hardware acceleration improves in some areas and makes no difference in others. I think they did a benchmark after re-enabling hardware acceleration of GDI and it wasn’t an across the board speed increase.
I guess as the blog you pointed out notes, hardware acceleration isn’t the panacea to cure all of life’s problems which probably explains why Apple was so reluctant to provide a interface for hardware accelerated decoding – I’ve run Flash 10.1 Gala and the hardware offloading of decoding has had negligible impact on over all CPU utilisation.
If you look at the HTML behind Web 2.0 applications, you’ll find that they’re not simple anymore, and the complexity can bog down a software-based renderer. Being able to offload the layout processing to the GPU helps a lot.
FireFox has hw accel on Linux since Version 2.0
it sounds almost like a real web browser!
It’s not a browser yet (IE9pp doesn’t even have a back button), it’s just a Trident instance. Microsoft still have every capability to totally screw up IE9 with the GUI. Almost nothing could be worse than IE8, but we will see…
Yes… let’s hope they stay focused on end features and functionality and also manage to get this thing completed in some reasonable amount of time.
I haven’t used IE regularly(except for unit testing at work, or in the past where sites were designed for IE) for at least a decade. Maybe MS can do something right here that fits nicely with Win 7… or they can drag their feet or even cancel the project… that wouldn’t surprise me either.
How is the UI of IE8 that much different from IE7? How many more ways are there to present Tabs, the address bar, and Navigational buttons?
It took them 9 versions, but FINALLY it’s starting to look like they’re able to build a decent browser…
MS5 was at the time, by far the best browser for Windows, especially compared to new version of Netscape that had just escaped from some mental institution.
Which is why they stuck with it for far too many years.
83/100 Acid3 score, that is significantly better than any previous version of IE. IE might slowly be getting there, and that is very welcome news.
For comparison purposes: I’m using Mozilla Firefox 3.7a6pre on Kubuntu right now, here is a screenshot I took of the previous version:
http://ourlan.homelinux.net/qdig/?Qwd=./KDE4_desktop&Qif=minefield_…
This alpha version of Firefox includes Webm support, and crash protection, but it does not yet include hardware-accelerated Cairo (for Canvas) rendering:
http://blog.mozilla.com/joe/2010/05/25/hardware-accelerating-firefo…
nor does it yet include JaegerMonkey for javascript speed-up:
https://wiki.mozilla.org/JaegerMonkey
So the development of IE9 is apparently ahead of Firefox 4 in some areas, and behind in others (it is still a little way behind in standards support), but nevertheless IE9 is showing a lot of promise indeed. This is a very good thing, IMO.
Google have a WebM codec for Directshow, but AFAIK in order for IE9 to be able to make use of WebM video there will have to be a codec for Media Foundation. I’d expect that Google are working on that right now.
I tried using 3.7a but the 64-bit version for Windows is still buggy.
Screen goes black when you hover over certain parts of pages. Otherwise it looks nice (FF overall, that is).
HW acceleration doesn’t work in Chrome (or if it does, very badly). Not that I/we NEED it yet. Anyway, when FF stabilizes a little more I will check it out again, it is looking pretty decent.
Difference between doing standards correctly, versus just doing standards.
Check the CSS tests on all of the major browsers, it offers a much clearer picture of the actual situation.
WebKit (the darling of the rendering engines) is particularly notorious for buggy or lacking implementations.
CSS 3 selectors fully supported in IE9 http://www.quirksmode.org/blog/archives/2010/06/ies_big_leap_fo.htm…
I’m actually really happy to see Microsoft having improved in this area so much. It would be nice if it is a precursor to their entire organizational mindset.
And no, there is no sarcasm in this. I’m genuinely glad.
Firefox 3.7a5 already supports Direct2D on windows.
gfx.font_rendering.directwrite.enabled;true
mozilla.widget.render-mode;6
And you should stick to 32bit versions for now because the 64bit versions haven’t had enough development time.
Firefox 3.7a5 already supports Direct2D on windows.
Any idea if they are going to support HW acceleration under Linux (or other OpenGL-supported platforms) and if so, when? Or will this again be a Windows-only feature?
it is not crystal-clear from this post, but it seems to indicate that hardware acceleration for Firefox is ordinarily via openGL, and optionally via Direct2D can be enabled instead for those people on Windows whose system’s support for openGL is abysmal.
http://hacks.mozilla.org/2010/04/mozilla-developer-preview-4-ready-…
Although Windows is being implemented first, support for OSX and Linux is promised to follow soon, and since it primarily uses OpenGL this shouldn’t be that difficult to get working on all platforms.
Firefox’s developers really like the Direct2D api because it is so easy to use. They are also working on a opengl version for other platforms such as linux. Ati seems to have ported Direct2D functionality to their linux driver so that might also be a possibility. Firefox wants to provide the same experience on every platform even smartphones.
Says who?
The OpenGL functionality was first. Lately the Firefox developers have added the yet-to-be-fully-debugged option of using Direct2D instead (this is not enabled by default) only to the Windows version of Firefox because OpenGL performance is abysmal on many Windows systems compared to what it should be.
http://www.phoronix.com/scan.php?page=news_item&px=Nzk5MQ
ATI has enabled their closed source Linux driver to use some of the same internal code for 2D acceleration as their Windows Direct2D driver. The Linux driver APIs remain unaffected, and there is no actual Direct2D API implemented in Linux (other than a partially-working dll in Wine).
With some luck, this improvement may eventually reliably bring ATI’s closed driver Linux 2D performance up to almost the level of 2D performance of the ATI OSS drivers. There have been some positive reports based upon the vast feedback in forum threads, while others are experiencing problems like the driver not even working.
http://www.phoronix.com/scan.php?page=article&item=amd_new_2d&num=1
Which Firefox does via using the OpenGL graphics API, since almost all smartphones don’t run Windows, and the Direct2D API is Windows-only.
Edited 2010-06-28 13:47 UTC
Microsoft have released IE9 Platform Preview 3, an application that gives developers access to the IE9 rendering engine (it’s not a full browser).
See the actual stupidity of actually comparing this basically non-fuctional nonsense to *FULL WORKING BROWSERS ON NON-MICROSOFT PLATFORMS*
Get a life Kroc.
It’s just a simple app to make use of the rendering engine. It is the rendering engine we are talking about here – not the the functionality of the application as a whole.
You CAN navigate to other sites – there is a primitive pop up text box where you can enter URLs. But this isn’t meant to be a complete and useful application, it is meant to showcase the most important part of the browser.
But I always have meant to ask. Why do you talk of companies like Microsoft and Apple using plural verbs instead of the standard (in English, that is) of singular verb? E.g. “Microsoft has…”
It always sounds odd when I see “Microsoft have” or “Apple were” here on OSNews. 🙂
Edited 2010-06-26 16:08 UTC
I would think t3h int4rweb would know by now that there are two main branches of English today (en-gb and en-us).
And everyone knows that GB-ers drive their cars on the wrong side of the road, too.
It is just an odd notation when referring to things as impersonal as large corporations. The singular collective usage seems to be more frequent than plural collective in most British books and publications I read. More interestingly, I’ve noticed OSNews will sometimes vary its usage within a given article, which makes it stand out more.
Typically a collective plural verb seems to be best applied when trying to emphasize the individuals within the collective.
Classic British English or some new bastardized form?
Try finding an old British headline that reads Germany have invaded Poland.
Single organizations use the singular form.
The use of “Microsoft have” rather than “Microsoft has” is because of the way collective nouns are treated. Read this: http://en.wikipedia.org/wiki/American_and_British_English_differenc…
The logic is that you wouldn’t refer to Microsoft saying, “He has released IE9PP3.” Instead, you would say, “They have released IE9PP3.” The British take it one step further. They stick to the plural sense at all time, out of consistency:
“[The people who develop IE] have released IE9PP3.”
“[They] have released IE9PP3.”
“[Microsoft] have released IE9PP3.”
Or in short, every time you refer to something that describes several people, even when the noun is singular (band, corporation, team, gang, fanclub, OSNews), you can treat it as plural. So, OSNews have done well. Kroc has done well.
______________
EDIT: I accidentally wrote “He have released IE9PP3.” in the example line. So much for confusion! Haha.
Edited 2010-06-26 17:17 UTC
The neuter form is one of the strange parts of English. I suspect “they” is often used since most people seem to prefer it to “it” or the “generic masculine.” Hence, people will speak of a singular person using “they” if they do not wish to specify a gender — even though that is incorrect.
Probably the best usage would be “Microsoft has announced… It will make the updates available…”
Interestingly, surveying the BBC, they are inconsistent in usage. I found some variation even within a single piece. Sloppy.
I do see your point. “Microsoft Corporation” is a single legal entity or juridical individual. So in that context, I think it is even better to refer to it in a singular sense.
It is these types of ambiguities that have warranted the use of the singular form, which is also a form of consistency. The rule of thumb I use myself is: “if I would replace the noun with a description of what it conveys, is the description singular or plural?”
Example:
“[The legal entity] has issued more shares.”
“Microsoft has issued more shares.” (singular)
“[The group of IE devs] have released IE9PP3.”
“Microsoft have released IE9PP3.” (plural)
The use of a singular sense has even expanded to plural nouns, such as “data”, the plural form of “datum”. Merriam-Webster provide a clear explanation with “usage”: http://www.merriam-webster.com/dictionary/data
OSNews is a single organization and should be treated as such.
OSNews has done well this year.
Great Britain has lost an empire and has not yet found a role.
Dude, you’re missing the entire point!
No you’re missing an English lesson.
Single entities always use the singular form.
No sentence should begin with Microsoft have.
Edited 2010-06-29 04:53 UTC
So you’re actually saying Kroc needs a lesson in English, and I should be in the same class?
Wow! Amazing.
“Windows Internet Explorer Platform Preview Setup does not support any operating system earlier than Windows Vista SP2.”
So much for the preview. For some XP/IE6 users that could be the first IE release worth upgrading to.
10 year old operating system. There’s more than IE that needs upgrading.
Still for sale until October this year. *
* no really, we mean it this time!
It’s only 2 years old if you count SP3 and 6 years old if SP2 (a major rework). It works very well and upgrade is not an option for many reasons. Sorry, XP is here to stay.
The problem is IE6, which is still hugely popular in some countries or organizations and its quirks are still shaping the web. I hoped IE9 would nudge at least some of IE6 users to use a standard compliant browser. Apparently that wasn’t the goal for Microsoft (not really a surprise, why to fight a won war if there are challenges elsewhere).
I’m curious to hear if they’ve fixed your previous grievances with the IE9 PP1/2, Kroc.
Yes and no. My website still doesn’t work, but it has progressed. According to the HTML5 spec, the <html>, <head> and <body> tags are optional, and the <body> should be implied when the browser hits a tag that isn’t specific to <head>; IE doesn’t do this right, and in pp3 it does it, but incorrectly puts the HTML5 <header> into the <head> and not the <body>.
Before, I was not convinced they were serious about standards, especially since their announcement about H.264 was so vile (the wording was dishonest to the last period), but this new preview shows firm, measurable commitment to HTML5 and standards. The H.264 thing is a whole ’other battle that goes beyond the scope of just the web and I don’t see Microsoft moving away from H.264 any more than Apple would. For now, WebM will be available for use if installed by the user, and that will be increasingly likely given Google/YouTube.
I’ve been using HTML5 since 2008 and I’ve been advocating to people to get learning it _now_, because by the time IE9 comes, those developers that have sat around waiting for IE will already be left in the dust by developers like me who have been making the most of HTML5 for years already in better browsers. Microsoft will have a struggle getting comfortable IE developers to get a clue.
I firmly believe that HTML5 will be the new base standard by which things get done on the web and IE9 could therefore be a runaway hit.
I don’t really like that aspect of the spec. I prefer it to be done explicitly. :/
Do you complain that the image tag allows multiple codecs? If it stuck with one when it was invented, then we’d all still be using XBMs for images.
No, just not specifying <body> and <html>. That sort of thing. I can’t help it, I am a programmer and I like to be explicit.
HTML itself is a simplified form of SGML. *shrug* I’m just pedantic by leaving them out, I doubt most developers will.
I am not sure I understand your reply. Pedantic?
In the general world of development, I know that few developers document, design, write to save memory, write to garner speed through efficiency, etc. It irks me that no one seems to care. All the memory, fast chips, the fancy interpreters and byte compilers, etc., seem to have made everyone sort of soft.
Sorry, not trying to poke at you. It’s just one of those things with me… like when someone touches my screen.
Only I would be concerned about an optional choice buried within the HTML5 spec that only IE doesn’t support.
I see! O.K.
😛
Just thought I’d be a geek and post a comment using IE9. It works, anyway.
IE9 is looking great using Microsoft tests, but 3rd party tests at http://www.html5test.com/ tell a different story. Currently IE9 scores 84+1 points in that test while other browsers get at least twice as much points.
I’m going to defend IE a little bit here I must be ill.
iPad Safari: 127 + 7
iOS 4 Safari: 185 + 7
Firefox 3.6.3: 139 + 4 (may not be latest I rarely run it so it may not have updated yet)
Opera 10.52: 129 + 4
Safari 5: 208 + 10
So out of those browsers it is only the latest versions of Safari (I don’t have chrome installed) that are more than 2* what IE gets. Yes I should be trying out nightly builds of everything but I’m using what is directly at hand.
Edited 2010-06-27 11:07 UTC
What seems to be a great archievement, FireFox does on Linux since Version 2.0 (Oct. 2010):
http://linuxhippy.blogspot.com/2010/06/ie9-to-be-gpu-accalerated-fi…
Funny thing
I get 1 FPS with 4 satellites using Google Chrome 5.0.375.70 on Windows Server 2008. With Firefox 3.6.4 on Windows I get 11-13 FPS. Looks like the hardware acceleration in Windows is rather spotty.
The amount of work presented here (and the manner in which it is presented) shows a firm commitment by Microsoft to participate in the web in a way that makes developer’s lives easier and allows for all new innovations in the native web. (H.264 aside, mind). As mentioned before, this is in stark contrast to Apple, and the Microsoft of the IE6 years.
Could you explain why you say this?
AFAIK Safari 5 (and WebKit in general) is the most ACID conformant browser. Which, is why – one would imagine – WebKit has been adopted by Google, RIM, and Nokia.
]{
I don’t think they care much at all about being ACID compliant. They chose WebKit because it’s fast, and therefore well suited to be run on phones and other low power devices, and because the codebase is by far the cleanest, easiest to understand, and easiest to integrate into their own products of the main browser engines.
True, but Apple also favors proprietary standards like H.264 and -webkit tags. Just like Microsoft did with IE in the old days : embrace (existing web standards), extend (with proprietary tags and ActiveX, unfair tactics to crush competition), extinguish…
Edited 2010-06-28 08:02 UTC
A browser prefix is the correct way to introduce new proposed features into CSS.
The browser prefix is a way to test the implementation practically, to see if it fulfills the need it was created for. For example, Webkit & Firefox (Gecko) implement background gradients with different syntax. I think it was first proposed and implemented by the webkit team, but the Firefox team decided that they preferred to implement it in a slightly different and simpler way.
After this is done and they get feedback, they discuss and decide which is the best implementation, and once it it finalized the prefix is removed.
Which is what was done in the latest webkit version, where the -wekit- prefix is no longer necessary to use border radius.
The prefix is used so that it is clear that this is not the final version, and to use with care.
BTW, just so you know, all the rendering engines have a prefix not just webkit.
Webkit: -webkit-
Gecko: -moz-
Opera: -o-
One more incentive that MS has for making sure IE9 is fast and compatible with modern web standards is their phone OS.
At least in the beginning, for their OS to be successful, it will need to be able to work with current mobile sites. And all the best mobile sites have been designed to work with iPhones & Android devices. If their browser fails here, it could hinder their new platform severely. All current smart phones are using webkit (iPhone, Android, WebOS, Blackberry, Nokia, Samsung Bada etc.) So they need something that works atleast as well as webkit.
Don’t mean to burst your bubble but I read somewhere that WP7 will have a variant of the IE7 rendering engine.
Link: http://www.neowin.net/news/windows-phone-7-browser-is-based-on-inte…
But yeah maybe future version of WP may benefit from all this.
Yeah I read about that somewhere, but I don’t think it’s been confirmed yet.
But it just makes no sense to me. Why go to all this trouble to prepare IE9, and then ship Windows Phone 7 a month or two early and not include IE9.
IE7 is slow, and non compliant, and will get loads of bad reviews. If MS is stupid enough to release Windows Phone 7 with an ancient browser, I’m pretty sure they will get a lot of bad reviews, and they will deserve each one.
I’m definitely not looking forward to start debugging even mobile browers for IE bugs 🙁
One more thing. Right now web designers & developers need to spend time fixing bugs in IE7 because it has such a large share.
But I can’t see that happening for mobile sites, where the good mobile browsers (webkit & opera) are already compliant and have a majority of the share.
The result will be that users browsing from IE7 on WinPhone7 will see a large majority of mobile sites broken, and they will rightly blame MS for that.
The latest news is that IE 9 will enter beta in August. Windows Phone 7 is supposed to be shipping in October. They simply won’t have stable IE 9 code ready in time for Windows Phone 7’s launch. That aside, they do plan to ship regular updates to the base platform just as they’ve done with Zune, so they’re likely to update the browser probably within a few months of IE9’s desktop release (i.e., however long it takes the mobile team to port and test the code following the desktop release).
The initial version of IE for Windows Phone 7 is a mix of 7’s rendering engine and some CSS/Javascript enhancements from 8.
Some info at the links below:
http://msdn.microsoft.com/en-us/library/ff462082(v=VS.92).aspx (webkit info on this page is outdated, see the blog)
http://live.visitmix.com/MIX10/Sessions/CL23 (this session basically mentions XHTML 1.0/XHTML-MP/HTML 4.01/ES3/DOM 1.0 / CSS 2.1)
http://blogs.msdn.com/b/iemobile/
I think the real question on everyone’s mind is when will we get 3D porn through a browser?