Chrome's FPS Histogram

Eberhard Gräther has improved the FPS meter in Chrome. I particularly like the histogram added on the right hand side. It allows you to easily see how long your frames are taking, and if your frame rate is bouncing around between different values.

You can check it out by

1. Opening up Chrome's developer tools (3 bar menu in upper right, Tools, Developer Tools)
2. Opening up the options (gear menu in bottom right)
3. Enabling 'Show FPS Meter' in the rendering section.

Or, in about:flags you can enable it always.

It's handy to see, e.g. when you are missing some frames and oscillating between 30 and 60fps:

State charts

Thanks to Bill Budge for pointing me to State Charts.

I've been carefully sussing out the logic of Chrome's Fullscreen controller into a finite state machine, mainly so that we can get a group to agree on exactly what we think it should be doing. Chrome can go fullscreen in numerous ways: users entering and exiting via a menu or button, web pages making the transition (e.g. when you make a video fullscreen by clicking on it in a page), extensions, a special mode on Mac, and Windows 8 Metro Snap. Most of these include asynchronous transitions, and all API initiated transitions must be serviced (even if we're 'in the middle' of another transition).

Initially the diagram resembled a flying spaghetti monster, I've been winnowing it down discarding states we can design out of the naive total possibility space. But, it's also much simpler to notate using clustering and history offered in state charts.

BTW, state charts are also included in UML state machines.

Pointer Lock (Mouse Lock) shipped in Chrome

Pointer lock has shipped with Chrome 22, it's out of Beta and releasing on time! Fancy demo first, check out Mozilla's First Person Shooter Demo.

Pointer lock offers the ability to hide the mouse cursor and use movement for controlling the camera without bumping into the edge of the screen or moving off the browser window. I've been working on it for some time, including writing the Pointer Lock specification.

It's been a long path. Things started with early prototypes and discussions of mouse lock in standards lists (and more, as it was renamed to pointer lock). Not everyone in the browser community was ready to just jump on board. It took some explaining, and still there were the those who think "Browsers are for looking at static documents, not web applications! This API is too powerful for the web." Also, people who wanted more, to the point of impracticality.

One challenge of specification was that I limited the resolution to be the same as mouse movement events without pointer lock. A direct connection to a high resolution mouse offers higher precision unaltered by an operating systems acceleration, or 'ballistic' algorithms. Sounds great, but how can this be specified, calibrated, and offered across browser vendors and operating systems? I stuck with keeping it simple and producing the exact same mouse movements received today, but without the limits of screen boarders or moving out of an application's focus area. More details in the spec FAQ.

I was pleased when David Humphrey jumped onto the Mozilla Issue. He is a professor at Seneca College and implemented Pointer Lock in Mozilla as a class project. They did great work, and eventually shipped to Firefox 14 a bit before Chrome.

One of the differences is that Firefox only allows pointer lock when pages have made an element full screen. This provides good security shelter, as Fullscreen had already been rigorously designed, implemented, and tested due to a real security threat (tricking a user to enter data into a website pretending to be another application). It was important to me to ship Chrome with non-fullscreen support on day 1, as I believe it to be a real need and wanted to discover security issues up front. The security policy in Chrome is split between the Chromium and WebKit open source projects, adding to that complexity.

On the topic of Fullscreen, there was a significant Pointer Lock API re-write in order to be as consistent as possible with the Fullscreen API. They do have many similarities, and are likely to be used at the same time by developers. However, I do lament using the Fullscreen style pointerlockchange and pointerlockerror events to notify a developer of success or failure. In my original specification I used callbacks. The advantage of callbacks is a guaranteed 1 to 1 correspondence of request and response. The events allow for cross talk between different bits code using the API, and are more fragile. On every event, code must validate if the event was due to a related request it had made (which it must keep track of).

With the help of Yuzhu Shen and others, we shipped an early version of Mouse Lock to Pepper plugins much earlier, including Native Client games. There security concerns were somewhat more relaxed as content using the API had to be published in the Chrome Web Store, as opposed to the open web. Via the store, we could have more control to remove content if it were misbehaving.

I'm looking forward to seeing new classes of applications implemented on the web using this API. ;)

Game Developers Conference 2012 presentation: The Bleeding Edge of Open Web Tech

I presented at GDC last week, and it went well. Here is a pre-recorded version of the talk. You can also check out the notes for the presentation.

One Year at Google

I've been at Google one year.

A lot has happened, but the vision stays the same. I and others are working on improving tech to support great applications on the web. Better performance, use of GPUs, 3D, and much more (audio, connectivity, device access, monetization, discovery, ...).

Google continues to build it's engagement with game developers. We're already engaging on multiple platforms (Android, Chrome, Google TV) and offering useful services (YouTube, AppEngine, Analytics, Ads) and building out great tech.

We've also continued hiring great game developers, and I'm humbled every day by the ones I'm working with. (e.g. people keep doing double takes that Bill Budge is working a few cubes down.) Ian Lewis has hit his stride and is doing a great job driving Game Developer Relations (btw: hiring) (and, well, all of Google is hiring really, even back in the Research Triangle NC, drop me a line if you'd like help applying).

Chrome GPU team is my home, though I'm still excited about Chrome OS where I started. There's a lot of core infrastructure for all GPU features, some of which are starting to ship, like WebGL.

20% time is a great perk at Google. Not everyone uses it, but I take a lot of it to help Game Developer Relations out and also do some game experiments.

Google was the hardest job I've joined yet, though. There's so much to learn, so much great tech and products, tons of fascinating things to look into, and so many rather smart folk. I love the culture, the positive "do the right thing" attitude, and that there are engineers all the way to the top. I'm excited for year 2. ;)

Working on Chrome OS at Google

Many have been curious what I'll be working on at Google, including myself for a while. Google is interesting in that you are not allocated to a team until just before your first day. You accept the job because you're a good fit for Google in general, not just one team.

I'm going to work on Chrome OS. There's a lot to do for the initial launch, but long term my goal is to help make it a great platform for rich graphical apps and games too.

Whoa, you say, I thought you worked on high performance games? Yes, high performance 3D games will be running inside browsers, with security and performance delivered via Native Client.