Microsoft to Co-Chair New W3C Web Performance Working Group
Earlier this morning the W3C announced the formation of a new Web Performance Working Group chartered with making it easier to accurately measure web application performance. Enabling web developers to understand the real world performance characteristics of their applications is critical to the success of HTML5, and we’re excited to have been selected as co-chairs of the new working group alongside Google. We look forward to partnering with the W3C and the broader web community to enable these scenarios through an interoperable API.
The first deliverable for the working group is to recommend an API that measures the performance of browser navigations. The WebTimings specification provides a good starting point for these capabilities, so this specification will move into the Web Performance Working Group and become the foundation for our recommendations.
The third Internet Explorer 9 Platform Preview was the first browser to implement these portions of the WebTimings specification. Following standard conventions, we used a vendor prefix (ms) on the name because the specification was still under active development and hadn’t been brought into the charter of any working group. Google also recently provided an early implementation of these API’s inside Chrome using their vendor prefix (webkit). Through early collaboration between our engineering teams, we almost have interoperable implementations which is impressive for an API that has only been discussed for a few months. This is a great example of what’s possible through collaborative partnerships at the W3C.
With two early implementations available, it shouldn’t take long to finalize an interoperable API and remove the vendor prefixes. We can’t do this alone though - the new working group needs your feedback to ensure we have the right design. Over the next few weeks we’ll post more details on the working group website and begin to solicit feedback. In preparation, you can try out these API’s using the IE9 Platform Preview or Chrome 6 nightly builds. To help you get started take a look at the msPerformance demo on the IE9 TestDrive which shows these API’s in action.
Jason Weber
Lead Program Manager for IE Performance
Comments
Anonymous
August 18, 2010
"we’re excited to have been selected as co-chairs of the new working group alongside Google." I bet the Richter Scale could pick up the tension in that room.Anonymous
August 18, 2010
Great. Now we'll have to hear about hardware accelerated marquee tags and how well IE9 interfaces to Office.Anonymous
August 18, 2010
Speaking of performance, is IE9 going to have a mechanism to fall back on CPU rendering if it detects a fast CPU with a slow GPU?Anonymous
August 18, 2010
Bob. the Richter Scale is not an instrument. Sheesh. Rob. Every vendor has the right to pitch their product. Everyone does it. You're just a little sensitive. Truth be told, IE9's GPU acceleration blows every browser out there out of the water right now. Yes, they'll catch up. Be happy.Anonymous
August 18, 2010
The comment has been removedAnonymous
August 18, 2010
Macrohard I doubt you can find a GPU so slow and a CPU so fast on the same machine that the CPU will render graphics faster.Anonymous
August 18, 2010
@Alex: IE9's hardware acceleration isn't much faster than Firefox 4's (YMMV). Opera isn't much slower than both, eventhough it DOESN'T use Direct2D hardware acceleration (it uses another acceleration technique). It is merely strongly optimized for Direct2D - all other browsers have to contend with platforms that don't have Direct2D at all (WinXP, OS X, GNU/Linux...) @Meni: VML includes a feature that allows more natural effects than SVG. However, the part that really blocks SVG is in its animation language: currently, it uses SMIL - while it would be more natural to use ECMAscript (which has 2 well-known implementations: Javascript and ActionScript). That part is being addressed (note that it is already possible to animate SVG with Javascript through SVG DOM manipulation, but it's not exactly streamlined) through a future revision of SVG. @Stilgar: case in point, an IGP on a quad core. Currently, most software rasterizers are badly optimized, which makes CPU rendering rather slow. However, some experimental or proprietary software multithreaded renders do work well (see how Opera works). Moreover, the problem with graphics isn't a matter of raw horsepower, but more of bus contention and latency: this happens when, say, an interface element is sent to the GPU for processing, then has to be read back in system RAM for CPU treatment, then sent back to the GPU. And when THAT happens, you can make a quad SLI on PCIe2.0 x16 mounted cards crawl down to a stop, even when running at full tilt with all lanes enabled. So, imagine about an IGP running in power saving mode on a single PCIe lane... In THAT case, a software renderer that blits to the graphics hardware will kick a hardware renderer's behind quite strongly.Anonymous
August 18, 2010
The comment has been removedAnonymous
August 18, 2010
Here some cool information about web workers: wearehugh.com/.../html5-web-workersAnonymous
August 18, 2010
@Meni "..sealed room, no one leaves until we have a standard.." If that is enforced with the current W3C, we need to have facilities to procreate and maternity wards.. schools and maybe highschools for the participants' children! ... because that's how long its going to take! :PAnonymous
August 18, 2010
The comment has been removedAnonymous
August 19, 2010
This is terrific. Thanks for the support.Anonymous
August 19, 2010
Does anyone find the fact that Firefox is using Direct2D like IE9 hilarious? I mean, it's exclusive to Windows Vista and 7, and its supposed to be a cross-platform browser. I wonder if they're using XPS for printing as well. It also shows that the D2D must be a way better technology than OpenGL for building hardware acceleration into the browser if they sacrificed cross-platform support for it. It also put them ahead of Chrome and Opera.Anonymous
August 19, 2010
@Raffi: Even if you would want to use OpenGL, developing the vector renderer on top of it would take considerable effort. Current Cairo OpenGL backends have not succesfully been made to perform sufficiently to date. Direct2D takes a lot of this work off our shoulders by providing an extremely efficient and complicated vector graphics renderer. Hence OGL would not really have been an option at all.Anonymous
August 19, 2010
@Raffi Specifically: derStandard.at: Firefox 4 is going to use hardware acceleration through Direct2D and DirectWrite on Windows, are similar things coming up for Linux and Mac OS X? Chris Blizzard: Within what's provided: Yes. We're trying to give the best experience possible on each platform. So for Windows Vista and 7 we see huge improvements when doing certain graphically intensive stuff. On OS X for example we have support for OpenGL for doing compositing, on Linux we do the same. But generally the Windows APIs that we have are better and more rich than what we have on other platforms. To give you an example: On Linux Cairo and Pixman were supposed to be fast, but unfortunately the underlying infrastructure never really got fast. On OS X we are actually pretty fast but Direct2D gives the performance advantage to Windows at the moment. Source: news.slashdot.org/.../Mozilla-Firefox-4-Will-Be-One-Generation-AheadAnonymous
August 19, 2010
The comment has been removedAnonymous
August 19, 2010
@jabcreations your versioning system has always made me chuckle. How can you be at Version 2.9 - if you are still in Alpha? Your website of course tops this - in a world where no one else versions theirs - you insist on being on version 2.8.5.2 or whatever number you are now on.... yet still output a 1990's UI.Anonymous
August 19, 2010
Will IE9 support web workers? Web worker support would allow for a HUGE performance gain on web apps my team has built.Anonymous
August 19, 2010
@Trevor - I think this is jabcreations' best comment: "I will run XP until I either find a Linux distro that doesn't annoy me or Microsoft undoes all the GUI destruction from Vista/7" So, he wants a Linux distro tailored just for him or MS roll back 5 years worth of interface changes in the next OS - just for him ;)Anonymous
August 20, 2010
Does anybody @ the IE9 Team know if Technet Subs are getting the Beta of IE9 soon? Thanks in advanceAnonymous
August 20, 2010
Each of jabcreations' posts makes me think he has a serious ego problem. And / or is desperate for attention.Anonymous
August 21, 2010
Does IE9 properly support the setAttribute method now? my tests still indicate that IE9 can't handle switching the "type" attribute round trip from various values on input fields. It looks like the name attribute has some similar, related issues as well. Thanks!Anonymous
August 21, 2010
@sally: We are not able to reproduce the issue you have reported. Please file a bug on CONNECT with the exact repro steps. Thanks!Anonymous
August 22, 2010
The comment has been removedAnonymous
August 22, 2010
The code you've provided works just fine in IE9-- the text is preserved as "test". Did you put your page in Standards Mode using the document type declaration?Anonymous
August 22, 2010
serves me right for not copy pasting from my test case files!!! start with a password input.... change the value to anything (user interaction vs. JS interaction), now change the field to a text input... value is lost.Anonymous
August 22, 2010
it sounds like your test case filez are bogus b/c you change your story now... it was "everything is broken" and now you say "the text value is cleared when a password input is changed to a text input." seems like a bug but no big deal.Anonymous
August 22, 2010
Actually, it might be a conscious decision to clear the password when the input field is converted to text (with security/privacy in mind): as a user I wouldn't trust IE if my password field randomly went from ***** to my password in clear!Anonymous
August 22, 2010
Open this GIF animation in IE9 Platform Preview 4: upload.wikimedia.org/.../Prince_of_Persia_%281989_video_game%29_IBM_PC_Version_gameplay.gif and zoom it. Notice the ugly visual artifacts. Please fix in the beta.Anonymous
August 22, 2010
@MakeUpUrMind - I'm sorry that I don't carry my entire browser test suite with me everywhere I go - I just happened to be bit by the "can't change the type attribute" bug in IE today and remembered that in IE9 is was only partially fixed - and since only the bugs that get constantly discussed have a chance of being fixed - I added my comment about this bug. Thanks though, you are right I should be drawn and quartered for forgetting it was a password, not a hidden field type, clearly all my test case files compiled over the years must therefore be bogus... after all I've only been doing professional web development since 1996. @Vince - Absolutely not! - this is a bug in the type fix's implementation in IE. At any point in time the value of the field is accessible (view-source), or via JavaScript e.g. elem.value and yes it IS A BIG DEAL because we all want a development platform that works in a standard way - cross browser. If the method were named Element.changeTypeAttributeOnAnyElementButEraseTheValueIfChangingFromPasswordToText(newType); Then I might accept that it is understood the method has limitations. However when the method is Element.setAttribute(attName, attValue); There is no implied limitations that 1 browser will only implement this for some attributes, only some of the time, with some undocumented side-effect behavior. Lets not forget that in IE6 and IE7 this bug was much worse... we just want it fixed - completely! webbugtrack.blogspot.com/.../bug-242-setattribute-doesnt-always-work.html Back in IE6, IE7 (both unfortunately still widely used today) there were dozens and dozens of attributes you could not set in IE. It would be a shame to see all this progress be for not.Anonymous
August 22, 2010
Will you also finally update the GUI icons and interfaces from back the Windows 95 days? :/ Like, img834.imageshack.us/.../ie1.pngAnonymous
August 23, 2010
@GIF The GIF looks fine to me in IE9 PP4 and see no artifacts when zoomed. Furthermore, I'll point out that it played faster/smoother in IE9 than Chrome which I appreciated!Anonymous
August 23, 2010
@GIF: We have a bug tracking the artifact issue, which can be seen, e.g. when the character runs from one place to another, ghosted outlines remain behind.Anonymous
August 27, 2010
@bull Stated that there will be "NO CONNECT BUG REPORT WILL BE FILED FOR THIS ISSUE" is just plain not intelligent. Filing and discussing bugs is what CONNECT is for. @Everyone Else The greatest mistake MS has made so far was disbanding the original IE team. And, I think everyone here knows that MS commtted many sins with IE5 and IE6. However, with the advent IE7 and IE8 I truly feel MS has atoned. The tremendous job MS has done in bringing true quality and adherence to standards to IE, whilst keeping true to backwards compatibility, has been nothing short of awe inspiring. JamesNTAnonymous
August 30, 2010
Very cool!
