AWS

This is a proxy error. Change you internet settings. This link will help. http://support.microsoft.com/kb/900936

It sounds like the board needs them in pairs. This is normal on many boards. This is sounding like a problem I had with a Tyan server board. You had to install the memory in a certain sequence. Slot 1 and 3 first, then boot, then shutdown and fill slots 2 and 4. Any other way and it would either not post or the OS would only see half the ram. Troubleshooting these types of problems is never easy.

Make sure you have create the www host header in IIS Manager.

Have you tested to be sure the ram slots are all good? Is the memory all the same kind by the same manufacturer? The only thing I can think of that would cause this is a dead slot or wrong type of memory for the board.

So rigt with any version prior to XPO. Now things are stable since more time is spent developing drivers which was the cause of the problem.

You need another key. You could try activating by phone. That might work, but, the keys from Dreamspark are MAC keys so only one activation per machine.

Make sure you have the permissions set to allow the remote user to connect.

When we first introduced our plans for Internet Explorer Platform Previews we said that &ldquodevelopers and people interested in standards and web development can try out new platform functionality and provide early feedback.&rdquo We are now getting such feedback on a daily basis and are using it to improve IE9. However, sometimes the impact of the feedback extends beyond just IE9. Here is the story of how some recent feedback regarding the third IE9 Platform Preview resulted in a correction to the new ECMAScript 5th Edition (ES5) standard for JavaScript. The ES5 standard became official in December 2009 and the third IE9 Platform Preview is the first widely distributed implementation of some subtle details of the ES5 specification. ES5 was designed to be highly compatible with existing websites and the Ecma International TC39 technical committee worked to avoid any non-security related changes that might break existing JavaScript code. However, perfection generally does not exist in the world of software so with the third IE9 Platform Preview we were very interested to see if any ES5-related compatibility problems with existing sites would show up. Soon after releasing this platform preview, we received reports that some web-apps that use the jQuery framework did not work correctly in the preview. We tracked the problem to a specific jQuery API method that in some cases passed a caller provided value to Object.prototype.toString without first checking if the value was null or undefined. Specifically, some calls to this jQuery method: isFunction: function( obj ) { return toString.call(obj) === "[object Function]" }, failed with an exception: &ldquoTypeError: Object expected&rdquo. Further analysis showed that toString in the above code was the built-in method Object.prototpe.toString and that the failures occurred when isFunction was being called with undefined as its argument. Why does an exception occur in IE9 and not in previous versions of IE or other browsers? It is because the third IE9 Platform Preview in standards mode actually conforms to the ES5 specification for Object.prototype.toString. According to the prior editions of the ECMAScript specification, calling any built-in method using null or undefined as the this value passes the &ldquoglobal object&rdquo (in browsers this is the DOM window object) to the method as its this value.

Welcome to your new Invision Power Board! Congratulations on your purchase of our software and setting up your community. Please take some time and read through the Getting Started Guide and Administrator Documentation. The Getting Started Guide will walk you through some of the necessary steps to setting up an IP.Board and starting your community. The Administrator Documentation takes you through the details of the capabilities of IP.Board. You can remove this message, topic, forum or even category at any time. Go to the documentation now...

I can't reproduce this out network server. We also have the same HP printers and staff is printing hundred page docs without a problem. I'll look at the way I set up the server and post my steps when I get a chance.

Lost In Translation &ldquoWeb design is 95% typography&rdquo. So much of the content produced and consumed on the web is text yet designers and users have been confined to a set of compatible fonts available across client operating systems. Escaping this typographical island has involved everything from cross-browser CSS workarounds, graphics-based solutions and even plug-ins, with trade-offs ranging from extra storage and bandwidth to reduced accessibility. As a result, typefaces have too often been one of the first casualties of the translation from Photoshop design mock-up to live web page. Not The Same CSS Solving this challenge required an interoperable CSS syntax to describe font resources. While IE added support for CSS2&rsquos @font-face rule as long ago as 1997, the differences between this earliest of implementations and the far more recent ones supporting CSS3 Fonts have given rise to CSS design patterns built to ensure the same rule works for all users. A notable example is the bulletproof @font-face syntax developed by Paul Irish from Google, et al. But crafting a cross-browser @font-face declaration turned out to be half the problem. No Common Web Font Format Internet Explorer&rsquos @font-face implementation supports EOT (Embedded OpenType) fonts, a compressed font encoding submitted to the W3C in 2008. Following WebKit&rsquos lead in 2007, Mozilla and Opera added support for raw TrueType and OpenType fonts. Raw fonts work well if your fonts&rsquo end-user license (EULA) allowed you to serve them from your web server. While this is true for many free fonts, this is not the case for the vast majority of commercial fonts. Web authors are thus effectively cut off from the richest font catalogs available. If they choose EOT they are able to license a number of commercial fonts for web use but only IE renders them. This leaves a challenge for the industry. The major browsers support two incompatible solutions and commercial font EULAs are generally incompatible with one of them.

The network plays a crucial role in the overall performance of a web browser. The best way to improve network performance is to minimize the volume of network traffic by using HTTP compression and taking advantage of the browser cache. We&rsquove made a tremendous number of improvements to the way that Internet Explorer 9 caches content to ensure that as many resources as possible are loaded from the cache. This post describes those improvements which are now available in the third IE9 Platform Preview which was released last month. Understanding Caching Let&rsquos start with a quick refresher on how caching works in browsers. At a high level, web browsers make two types of requests over HTTP and HTTPS&mdashconditional requests and unconditional requests. An unconditional request is made when the client browser does not have a cached copy of the resource available locally. In this case, the server is expected to return the resource with a HTTP/200 OK response. If the response&rsquos headers permit it, the client may cache this response in order to reuse it later. If the browser later needs a resource which is in the local cache, that resource&rsquos headers are checked to determine if the cached copy is still fresh. If the cached copy is fresh, then no network request is made and the client simply reuses the resource from the cache. If a cached response is stale (older than its max-age or past the Expires date), then the client will make a conditional request to the server to determine whether the previously cached response is still valid and should be reused. The conditional request contains an If-Modified-Since and/or If-None-Match header that indicates to the server what version of the content the browser cache already contains. The server can indicate that the client&rsquos version is still fresh by returning HTTP/304 Not Modified headers with no body, or it can indicate that the client&rsquos version is obsolete by returning a HTTP/200 OK response with the new version of the content. Obviously, conditional requests result in better performance than unconditional requests (because the server need not retransmit the entire file if the client&rsquos version is fresh) but the best performance is obtained when the client knows that the version in its cache is fresh and the conditional revalidation can be avoided entirely. Extremely Long-Life Cache Headers While RFC2616 recommends that servers limit freshness to one year, some servers send Cache-Control directives specifying a much longer freshness lifetime. Prior to IE9, Internet Explorer would treat as stale any resource with a Cache-Control: max-age value over 2147483648 (2^31) seconds, approximately 68 years. With Internet Explorer 9, we now accept any value up to 2^63 for the max-age value, although internally the freshness interval will be truncated to 2^31 seconds. Vary Improvements The HTTP/1.1 Vary response header allows a server to specify that a fresh cached resource is valid for future reuse without server revalidation only if the specified request headers in the later request match the request headers in the original request. For example, this enables a server to return content in English with a Vary: Accept-Language header. If the user later changes their browser&rsquos Accept-Language from en-US to ja-JP, the previously cached content will not be reused, because the Accept-Language request header no longer matches the request header at the time that the original English response was cached. With Internet Explorer 9, we&rsquove enhanced support for key Vary header scenarios. Specifically, IE9 will no longer require server revalidation for responses which contain Vary: Accept-Encoding and Vary: Host directives. We can safely support these two directives because: All requests implicitly vary by Host, because the host is a component of the request URL. IE always decompresses HTTP responses in the cache, making Vary: Accept-Encoding redundant. Like IE6 and above, IE9 will also ignore the Vary: User-Agent directive. If a response contains a Vary directive that specifies a header other than Accept-Encoding, Host, or User-Agent (or any combination of these) then Internet Explorer will still cache the response if the response contains an ETAG header. However, that response will be treated as stale and a conditional HTTP request will be made before reuse to determine if the cached copy is valid. Redirect Caching Internet Explorer 9 now supports caching of HTTP redirect responses, as described by RFC 2616. Responses with Permanent Redirect status (301) are cacheable unless there are headers which forbid it (e.g. Cache-Control: no-cache) and those with Temporary Redirect status (302 or 307) are cacheable if there are headers which permit it (e.g. Cache-Control: max-age=120). While this significantly improves performance, web applications that are misconfigured might not work as expected after this change. For example, we&rsquove found a few commonly-visited sites that use a pattern which looks like this: > GET / HTTP/1.1 > GET /SetCookie.asp HTTP/1.1 The site&rsquos goal is to have the homepage determine if the user has a cookie set, and if not, send them to a page that sets the cookie. The problem is that the server has chosen a 301 for this task, and a 301 is cacheable. Hence, IE will simply redirect between these two cached redirects on the client (never again contacting the server) until the user gets bored and closes the browser. Notably, any version of IE would hit a redirect loop in the scenario above if the user had disabled cookie storage for the site in question. If your site makes use of redirects, you should ensure that it is configured to avoid redirect loops by ensuring that any redirect that relies upon side-effects (e.g. testing or setting a cookie) is marked uncacheable. HTTPS Caching Improvements A few months ago, I mentioned that Internet Explorer will not reuse a previously-cached resource delivered over HTTPS until at least one secure connection to the target host has been established by the current process. This can cause previously-cached resources to be ignored, leading to unconditional network requests for content that was already in the local cache. In IE9, the unnecessary cross-host HTTPS requests are now conditional requests, so the server can simply return a HTTP/304 Not Modified response for unchanged content. While a round-trip cost is still incurred, significant performance improvements are gained because the server does not need to retransmit the entire resource. Back/Forward Optimization For IE9, we&rsquove made improvements so that clicking the back and forward buttons results in faster performance. RFC2616 specifically states that a browser&rsquos Back/Forward mechanisms are not subject to cache directives: History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved. By default, an expiration time does not apply to history mechanisms. If the entity is still in storage, a history mechanism SHOULD display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents. In previous versions of Internet Explorer, when the user navigated back or forward, IE would check the freshness of resources if they had been sent with the must-revalidate cache-control directive, and in numerous other circumstances depending on how recently the resource was downloaded. In IE9, the INTERNET_FLAG_FWD_BACK flag behaves as described on MSDN, and IE will not check the freshness of cached resources when the user navigates Back or Forward. As a result of this optimization, Internet Explorer 9 can perform far fewer conditional HTTP requests when navigating with Back and Forward. For example, the following table shows the improvement when going Back to a typical article on a popular website: IE8 IE9 Improvement Back/Forward Navigation Request Count: 21 Bytes Sent: 12,475 Bytes Recv: 216,580 Request Count: 1 Bytes Sent: 325 Bytes Recv: 144,617 Request Count: -20 (-95%) Bytes Sent: -12,150 (-97.4%) Bytes Recv:-71,963 (-33.3%) Now, I mentioned that we ignore caching directives when navigating back and forward, so alert readers may be wondering why IE9 still makes one request when clicking Back on this site. The reason is that IE will not commit to the cache any uncacheable resource. An uncacheable resource is one delivered with a Cache-Control: no-cache directive or with an Expires date in the past or an Expires date not later than the Date header. Therefore, the browser is forced to redownload such resources when the user navigates Back and Forward. To improve performance and enable a resource to be reused in Back/Forward navigation while still requiring revalidation for other uses, simply replace Cache-Control: no-cache with Cache-Control: max-age=0. Unlike the other improvements in described in this post, back/forward optimizations are not visible in the Platform Preview build because it does not have a back button. Heuristic Cache Improvements Best practices recommend that web developers should specify an explicit expiration time for their content in order to ensure that the browser is able to reuse the content without making conditional HTTP requests to revalidate the content with the server. However, many sites deliver some content with no expiration information at all, relying upon the browser to use its own rules to judge the content&rsquos freshness. Internet Explorer allows the user to configure what should happen when content is delivered without expiration information. Inside Tools > Internet Options > Browsing history > Settings, you will see four options: These four options have the following behavior: Every time I visit the webpage Any resource without explicit freshness information is treated as stale and will be revalidated with the server before each reuse. Every time I start Internet Explorer Any resource without explicit freshness information is validated with the server at least once per browser session (and every 12 hours thereafter in that session). Automatically (Default) Internet Explorer will use heuristics to determine freshness. Never Any cached resource will be treated as fresh and will not be revalidated. These options only control the browser&rsquos behavior when content is delivered without expiration information if the content specifies an explicit policy (e.g. Cache-Control: max-age=3600 or Cache-Control: no-cache) then the browser will respect the server&rsquos directive and the options here have no effect. In earlier IE versions, the Automatic Heuristics were simple and only affected cached images, but IE9 improves the heuristics to match RFC2616&rsquos suggested behavior: if the response does have a Last-Modified time, the heuristic expiration value SHOULD be no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%. If Internet Explorer 9 retrieves a cacheable resource which does not explicitly specify its freshness lifetime, a heuristic lifetime is calculated as follows: max-age = (DownloadTime - LastModified) * 0.1 If a Last-Modified header wasn&rsquot present in the server&rsquos response, then Internet Explorer will fall back to the &ldquoOnce per browser session&rdquo revalidation behavior. As a result of the improvement to heuristic caching, Internet Explorer 9 can perform far fewer conditional HTTP requests when reloading many pages. For example, the following table shows the improvement when revisiting a typical article on a popular website: IE8 IE9 Improvement Revisit in new browser session (PLT2) Request Count: 42 Bytes Sent: 26,050 Bytes Recv: 220,681 Request Count: 2 Bytes Sent: 1,134 Bytes Recv: 145,217 Request Count: -40 (-95.3%) Bytes Sent: -24,916 (-95.6%) Bytes Recv: -75,464(-34.2%) The Caching Inspector in Fiddler will show you when a response expires, based on the headers provided on that response. For instance, here&rsquos what you see for a response which contains an ETAG and Last-Modified header, but no expiration information: Other Networking Improvements In this post, I&rsquove enumerated the improvements in Internet Explorer&rsquos caching code that help ensure web sites can make the most efficient possible use of the network. Of course, web developers should continue to follow best practices and specify their desired cache behavior using the Expires and Cache-Control headers, but even sites that fail to do so will load more quickly in IE9. In a future post, I&rsquoll describe other improvements we&rsquove made to the IE9 Networking Stack to further improve page load times. -Eric Lawrence View the full article

Bulletin Severity Rating:Important - This security update resolves a privately reported vulnerability. The vulnerability could allow remote code execution if a user opened an attachment in a specially crafted e-mail message using an affected version of Microsoft Office Outlook. An attacker who successfully exploited this vulnerability could gain the same user rights as the local user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights. View the full article

Bulletin Severity Rating:Critical - This security update resolves two privately reported vulnerabilities in Microsoft Office Access ActiveX Controls. The vulnerabilities could allow remote code execution if a user opened a specially crafted Office file or viewed a Web page that instantiated Access ActiveX controls. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights. View the full article

Bulletin Severity Rating:Critical - This security update resolves a publicly disclosed vulnerability in the Canonical Display Driver (cdd.dll). Although it is possible that the vulnerability could allow code execution, successful code execution is unlikely due to memory randomization. In most scenarios, it is much more likely that an attacker who successfully exploited this vulnerability could cause the affected system to stop responding and automatically restart. View the full article

Bulletin Severity Rating:Critical - This security update resolves a publicly disclosed vulnerability in the Windows Help and Support Center feature that is delivered with supported editions of Windows XP and Windows Server 2003. This vulnerability could allow remote code execution if a user views a specially crafted Web page using a Web browser or clicks a specially crafted link in an e-mail message. The vulnerability cannot be exploited automatically through e-mail. For an attack to be successful, a user must click a link listed within an e-mail message. View the full article

Welcome to the community. We're here to help when you need it.

Last week, a passel of leaked PowerPoint slides appeared to give a sneak peek of Microsoft's plans for Windows 8. (I should call them "alleged Microsoft PowerPoint slides" or something, but Mary Jo Foley and Ina Fried are accepting them as the real deal-and that's good enough for me.) Among the features mentioned: A new technology for superfast startups (a perennial boast of new versions of Windows dating at least back to Windows 98), multiuser login via face recognition, an improved help system, and a tool for restoring Windows to its original settings without munging your data. The company would apparently like to help PC makers build machines that have some of the "it just works" reliability associated with Macs. (It turns out that consumers are willing to pay for a better experience-apparently, the price premium that Apple commands is about more than unicorn tears.) It would be a mistake to take the leaked slides as a definitive guide to the upcoming OS: Windows 8 is still early in the development process, and the details in the deck were prepared to address early questions from hardware types, not to serve as an overarching prospectus. And Microsoft's early pitches for forthcoming versions of Windows usually haven't been a terribly reliable predictor of the products it's actually shipped-just ask anyone who took the initial scuttlebutt about Vista very seriously. But thinking about Windows 8 left me mulling over what I'd like to see when the the OS (which may well be called something other than Windows 8) arrives. Here's my quick wish list-I'm assuming that Win 8 will still be recognizably Windowsesque rather than an utter reimagining for the Web era... Full story: PC World

Details are starting to leak about features and functionality Microsoft is planning for the next version of the operating system, which may or may not be called Windows 8. Over the weekend, Francisco Martin Garcia, a Microsoft Active Professional partner based in Madrid, Spain, posted purported internal Microsoft slides that suggest Windows 8 will include faster startup times, 3-D graphics support, USB 3.0 and Bluetooth 3.0 connectivity, and the ability for users to log in via facial recognition technology. The blog Microsoft Kitchen published several additional slides Monday that are dated April 2010. The information in the slides is sparse, but there are plenty of revealing tidbits. With Windows 8, Microsoft is planning to launch an application store from which users will be able to buy apps for PCs and other devices that run Windows. One slide describes it as "Store as a Service" and notes that Microsoft sees its developer army as a significant advantage to getting up and running quickly. "It's clear that the 'Windows Store' will be a software service Microsoft provides and hosts fully in the cloud," the Microsoft blog Neowin reported Monday. "The company will likely build the distribution model on Windows Azure to lure application developers." Windows 8 will also give partners plenty of opportunities to differentiate their hardware and software through customization. In one slide titled "How Apple Does It", Microsoft notes how the user experience associated with Apple products helps quickly establish their value in the minds of consumers. While Apple fans will feel vindicated by this, Microsoft can legitimately say it's able to give customers want they want in a way that it wasn't able to prior to Windows 7. Performance in Windows 8 is also earmarked for improvement. For slates and laptops, Microsoft is focusing on resume-from-sleep performance of less than one second, according to one slide. "Windows 8 PCs turn on fast, nearly instantly in some cases, and are ready to work without any long or unexpected delays," reads one of the purported Microsoft slides. Microsoft is also planning to connect Windows accounts to the cloud so that users' settings and preferences can follow them to any device they use, according to one slide. A Microsoft representative told CRN the company is still investigating the validity of the slides. However, given the company's unwavering refusal to comment on Windows 7-related rumors that surfaced prior to its launch, it's a good bet that "Microsoft doesn't comment on future versions of Windows" will be the official response. Source: CRN

Looks like Windows 8 is starting to come into focus. Read this at Mary Jo Foleys blog this morning. Source: All About Microsoft

A few weeks ago, we talked about the performance characteristics of our Flickr Explorer sample. We showed how hardware acceleration benefits real world scenarios such as browsing photos, and how easily web developers can build these types of applications. Recently, we released a new set of demos alongside the third IE9 Platform Preview. Today we&rsquore going to discuss the Amazon Shelf concept application (also see the companion Channel 9 video). Much like Flickr Explorer, Amazon Shelf is written using standard HTML, CSS and Javascript. Amazon Shelf also incorporates a key new HTML5 feature &ndash the canvas element. Canvas is an incredibly powerful way to draw directly to the screen using simple Javascript API calls. When you launch Amazon Shelf, you&rsquore shown a list of the top selling books from Amazon. This data is retrieved using the Amazon Product Advertising API. You can search for specific books, browse, and &ldquoopen&rdquo books to view detailed information and customer reviews. This demo uses common patterns that you find across many interactive web applications and games. There is one main loop that updates the books and other objects on the screen, and performs simple hit testing to support interacting with the elements on the canvas. Canvas, like all graphics in IE9, is fully hardware accelerated by default. When IE9 users browse to a website that uses canvas, IE will automatically leverage the full capabilities of the PC to provide a great experience with levels of performance not possible with today&rsquos browsers. Using IE9, Amazon Shelf is generally able to maintain a responsiveness of 60 frames per second, which is considered realtime. Today&rsquos browsers are only able to achieve framerates of 1-8fps which is a small fraction of the performance provided by IE9. We recently blogged about using the Windows Performance Tools to analyze browser performance. Using these tools, we&rsquove taken some measurements of loading Amazon Shelf in the top browsers available today. We used the same hardware and methodology discussed in the past. Let&rsquos look at the CPU and GPU activity graphs to better understand how the demo performs in these browsers. Note: Internet Explorer 8 is not included in this comparison since it does not support the Canvas element. First up is Chrome 5. Chrome is able to update the screen once every 0.99 seconds, yielding a frame rate of about 1 FPS during the bookshelf load animation. This results in a very slow, choppy experience. One core on this dual core machine is fully utilized, and the GPU is not employed by the browser at all. Here are the results for Safari 5. During the load animation, Safari does not attempt to render the scene at all, resulting in an effective 0 frames per second. Again, one core on the CPU is fully utilized and the GPU remains untouched. Next up, Firefox 4 Beta. We used Minefield 4.0b2pre nightly for this analysis. Again, our tests ran this latest nightly build of Firefox (like all the others) in the default configuration. This means hardware rendering with the GPU was not enabled in Firefox. Here are the results for Firefox. The animation is rendered properly, and the screen is updated twice every .25 seconds, yielding a frame rate of about 8 FPS. Finally, let&rsquos take a look at Internet Explorer 9 Platform Preview 3. We see that IE9&rsquos full usage of the GPU results in a steady, smooth frame rate of 60 FPS. The CPU handles the task without any trouble and rests frequently while the GPU renders Amazon Shelf to the screen. There is a meaningful difference in the experience when running the demo in IE9 compared to other browsers. Check out Amazon Shelf on www.ietestdrive.com to see for yourself. We&rsquod like to thank Amazon for their help in putting this demo together, and embracing the new GPU powered, standards based markup enabled by Internet Explorer 9. Our team can&rsquot wait to see what other graphically rich experiences web developers armed with hardware accelerated Canvas will dream up! Seth McLaughlin Program Manager for IE Performance View the full article

I have upgraded the forum to the newest version of IPB. There are some new features so make sure to check your user control panel to take full advantage of the new options. I have also removed all the ads for members. Guests will still see the ads. Once you join the ads will disappear. This was done to make your user experience more enjoyable while still allowing the site to be self supporting. I will be adding a donation system in the future if you'd wish to contribute to the site.

var ctx0, ctx1 var canvas0, canvas1 var wave = 1 var direction = 1 var timer var HEIGHT2 = 100, WIDTH2 = 400 var count = 0 var currentX = 0, currentY = 0, lastX = 0, lastY = 0 var r = Math.floor(Math.random() * 255) + 70 var g = Math.floor(Math.random() * 255) + 70 var b = Math.floor(Math.random() * 255) + 70 window.onload=init function init() { // Check to see if canvas is supported if (!document.createElement('canvas').getContext) return // Set up canvas0 ctx0 = document.getElementById("canvas0").getContext("2d") ctxWidth = document.getElementById("canvas0").width ctxHeight = document.getElementById("canvas0").height // Set up canvas1 canvas1 = document.getElementById("canvas1") ctx1 = canvas1.getContext("2d") ctx1.lineWidth = 25 ctx1.lineCap = "round" // Add event handlers if (canvas1.addEventListener) canvas1.addEventListener("mousemove", OnMouseMove, false) else if (canvas1.attachEvent) canvas1.attachEvent("onmousemove", OnMouseMove) // Start the renderLoop timer = setInterval(renderLoop, 16) } function OnMouseMove(e) { if (typeof e == 'undefined') e = canvas1.event if (typeof e.offsetX != 'undefined' && typeof e.offsetY != 'undefined') { currentX = e.offsetX currentY = e.offsetY } else { var relPos = getRelativePos(e.clientX, e.clientY) currentX = relPos[0] currentY = relPos[1] } } // My thanks to QuirksMode.org for the insight here function getRelativePos(x, y) { var curleft = curtop = 0 var obj = document.getElementById('canvas1') if (obj.offsetParent) { do { curleft += obj.offsetLeft curtop += obj.offsetTop } while (obj = obj.offsetParent) } // Webkit isn't compliant with CSS OM View here thus, we need to grab scrollTop from body instead of documentElement if (document.body.scrollLeft > 0) { var scrollLeft = document.body.scrollLeft } else { scrollLeft = document.documentElement.scrollLeft } if (document.body.scrollTop > 0) { var scrollTop = document.body.scrollTop } else { scrollTop = document.documentElement.scrollTop } return [(x - curleft + scrollLeft), (y - curtop + scrollTop)] } function drawLines(ctx, x, y) { ctx.save() ctx.beginPath() ctx.moveTo(lastX, lastY) ctx.lineTo(x, y) ctx.strokeStyle = "rgba(" + r + "," + g + "," + b + ", 1)" ctx.stroke() ctx.restore() } function clearLines(ctx) { // Clear first ctx.fillStyle = "rgba(0,0,0,0.05)" ctx.fillRect(0, 0, WIDTH2, HEIGHT2) // Change up color if (count++ > 50) { count = 0 r = Math.floor(Math.random() * 255) + 70 g = Math.floor(Math.random() * 255) + 70 b = Math.floor(Math.random() * 255) + 70 } } function renderLoop() { // Draw lines clearLines(ctx1) drawLines(ctx1, currentX, currentY) lastX = currentX lastY = currentY drawSimpleShapes(ctx0) } function drawSimpleShapes(ctx) { // Draw background if (wave >= 60 || wave

We&rsquore focused on making Internet Explorer 9 amazingly fast, and we want to help web developers make their sites fast as well. Enabling developers to accurately measure the performance of their websites is critical to making the web faster and enabling a new class of HTML5 applications. At Velocity, we announced Internet Explorer 9 as the first browser to provide performance information to developers at runtime, which we introduced in the latest IE9 platform preview. With special thanks to Steve Souders and Zhiheng Wang from Google, the WebKit team and Mozilla. Measuring real-world performance of websites is difficult and error prone today. Developers are forced to use hacks, such as injecting low resolution JavaScript timestamps throughout their code, which slows down the pages for end users, introduces an observer effect, and provides inaccurate results which can drive the wrong behavior. The browser knows exactly how long it takes to load and execute a webpage, so we believe the right solution is for the browser to provide developers an API to access these performance results. Web developers shouldn&rsquot have to think about how to measure performance &ndash it should just be available for them. It&rsquos important for this API to be interoperable across all browsers and platforms so that developers can consistently rely on these results. The Web Timing specification at the W3C is a good foundation for solving this problem in an interoperable manner. The implementation that you&rsquoll find in the latest IE9 platform preview is based off the navigation section of Web Timings and we&rsquove started conversations with the W3C and other browser manufacturers about working together to get Web Timing chartered and broadly supported. Let&rsquos take a closer look at how developers are forced to measure performance today and what the new API&rsquos enable. How Developers Measure Performance Today Today, in order to collect performance metrics a web developer has to instrument their code with specific timing markers at strategic places on their web page. This can result in code that opposes performance best practices. Developers write something like this: var start = (new Date).getTime() /* do work here */ var pageLoad = (new Date).getTime() - start This approach has several problems. It forces the JavaScript engine to load earlier than normal. It forces the HTML and JavaScript parsers to switch contexts. It may block parallel requests to load the remaining resources. Something else to mention is that this JavaScript approach does not capture network latency timings, which is the time associated from when the document is initially requested from the server to the time it arrives and is displayed to the end-user. Additionally, while the Date function is available across all browsers, the results vary in precision. John Resig has a nice blog post in which he goes to some lengths to determine that the time from (new Date).getTime() is as precise as 7.5ms on average across browsers, half the interval for the Windows system timer at 15ms. Many operations can execute in under 1ms which means that some measurements can have an error range of 750%! How Developers can Measure Performance with Internet Explorer 9 The third Internet Explorer 9 platform preview contains a prototype implementation of the Web Timings NavigationTiming interface called window.msPerformance.timing. Following convention, we use a vendor prefix (ms) on the namespace because the spec is under development. There are no other implementations yet, and therefore no interoperability with other browsers. This interface captures key timing information about the load of the root document with sub-millisecond accuracy, which is immediately available from the DOM once the page had loaded. window.msPerformance.timing interface MSPerformanceTiming{ readonly attribute unsigned longlong navigationStart readonly attribute unsigned longlong fetchStart readonly attribute unsigned longlong unloadStart readonly attribute unsigned longlong unloadEnd readonly attribute unsigned longlong domainLookupStart readonly attribute unsigned longlong domainLookupEnd readonly attribute unsigned longlong connectStart readonly attribute unsigned longlong connectEnd readonly attribute unsigned longlong requestStart readonly attribute unsigned longlong requestEnd readonly attribute unsigned longlong responseStart readonly attribute unsigned longlong responseEnd readonly attribute unsigned longlong domLoading readonly attribute unsigned longlong domInteractive readonly attribute unsigned longlong domContentLoaded readonly attribute unsigned longlong domComplete readonly attribute unsigned longlong loadStart readonly attribute unsigned longlong loadEnd readonly attribute unsigned longlong firstPaint readonly attribute unsigned longlong fullyLoaded } For the first time, web developers can accurately understand how long it takes to load their page on their customer&rsquos machines. They have access to when the end-user starts navigation (navigationStart), the network latency related to loading the page (responseEnd - fetchStart), and the elapsed time to load the page within the browser. Developers can use this information to adapt their applications at runtime for maximum performance, and they can use their favorite serialization interface to package these timings and store them on the server to establish performance trends. With JSON, this would look something like this: JSON.Stringify(window.msPerformance) Another useful feature of window.msPerformance is the ability to only query for the elapsed time taken in important time phases of loading the document called timingMeasures. window.msPerformance.timingMeasures interface MSPerformanceTimingMeasures{ readonly attribute unsigned longlong navigation readonly attribute unsigned longlong fetch readonly attribute unsigned longlong unload readonly attribute unsigned longlong domainLookup readonly attribute unsigned longlong connect readonly attribute unsigned longlong request readonly attribute unsigned longlong response readonly attribute unsigned longlong domLoading readonly attribute unsigned longlong domInteractive readonly attribute unsigned longlong domContentLoaded readonly attribute unsigned longlong domComplete readonly attribute unsigned longlong load readonly attribute unsigned longlong firstPaint readonly attribute unsigned longlong fullyLoaded } Simply access window.msPerformance.timingMeasures.navigation after the page has been loaded and you have the time taken to perform the navigation to the loaded document. Finally, the window.msPerformance.navigation interface contains information such as the type of navigation and additional network activity that occurred on the page to help describe the overall navigation experience. window.msPerformance.navigation interface MSPerformanceNavigation{ const unsigned short NAVIGATION = 0 const unsigned short RELOAD_BACK_FORWARD = 1 readonly attribute unsigned longlong type readonly attribute unsigned longlong redirectedCount readonly attribute unsigned longlong uniqueDomains readonly attribute unsigned longlong requestCount readonly attribute unsigned longlong startTime } Let&rsquos look at it in action On the IE9 Test Drive site, you can try the window.msPerformance Test Drive demo. There you see a visualization of the time to load the demo page as shown below. In this example, the overall navigation took 111ms to go from when the link is clicked to the time the contents are loaded within the platform preview. Check it out! Everything described here is available now in the third platform preview. Check it out at http://ietestdrive.com and try out the window.msPerformance Test Drive demo. This interface is a prototype of a working draft. The API may change, but we want to release this early so that developers can begin to use the API and provide feedback. Please give window.msPerformance interface a try and let us know what you think by providing feedback through the Connect. Anderson Quach Program Manager Edit 6/29 - correction in sentence describing demo page load time.

Welcome to the community Kelly.