What happens when you switch to a Gmail tab on OS X

What follows is a brief walk through of what happens when you switch to a Gmail tab. You can follow along in the profile.

The process starts with [GeckoNSApplication sendEvent:] for the mouse event. This travels on down to nsXBLEventHander::HandleEvent(). From there, we call into the JS, specifically onxblmousedown() in tabbox.xml(). This eventually calls into set__selected() and set_selectedPanel(). set_selectedIndex() calls onselect() in browser.xul which ends up taking about 14ms. During onselect() we spend 4ms decoding an image, 3 ms in callProgressListeners() and 3ms in GetBoundingClientRect(). The whole process of handling the click event takes about 15ms.

After that we spend 6ms handling some events. Among these are a RefreshDriver tick and a toolkit paint. Afterwards we wait for 12ms.

33 ms after the original click we start the painting process. First we do a [NSView viewWillDraw] which calls in PresShell::WillPaint() and takes 3ms. Finally we start the actual 85 ms paint in PresShell::Paint().

Here's the breakdown of what we doing during paint. Of the 85 ms, 81 ms is in LayerManagerOGL::Render(). 5ms of that is clearing the surface in BasicBufferOGL::BeginPaint(), 11 ms is texture upload which does a useless format conversion (bug 613046). In between these two is 58ms of DrawThebesLayer() of which 39 ms is BasicLayerManager::EndTransactionInternal doing composition. A lot of this seems to be vm badness caused by cairo/CoreGraphics and it's weird copy-on-write semantics. The rest of the time is 6ms in nsDisplayText::Paint, 5 ms in nsDisplayBackground::Paint, 4 ms in nsDisplayBorderBackground::Paint, and 3ms in nsDisplayBorder::Paint(). Unfortunately, of the 85 ms only 18ms of the time is painting display items and of the 18ms less than half of that is actual painting operations inside of CoreGraphics.

Shortly after PresShell::Paint() the new content is displayed on the screen and we run a couple more different events and a garbage collection.  And that's what happens during the 130ms switch to a Gmail tab.

Resizable windows in Ubuntu

By default, Ubuntu ships with window resizers that are very small and difficult to hit exactly with the mouse. This is made worse by the fact the resize cursor jumps to a different location. You can fix this by switching to the High Contrast theme. This adds a visible resizer to some windows. It does make the rest of the UI look terrible, but that's a price I'm willing to pay to be able to resize my terminals.

Azure canvas on OS X

Firefox 12 is the first release that we use the new CoreGraphics backend for canvas. This brings a host of performance improvements, that largely come from removing overhead and semantic mismatches between HTML canvas and CoreGraphics.

Here are some examples:
GUIMark2 vector test 6.29 fps to 6.63 fps
GUIMark2 Bitmap From 17.62 fps to 22.9 fps
Fish IE goes from a high quality but embarrassing 7fps with 10 fish to 48fps with 250 fish.

Checkerboarding CNN.com

The graphics team has been spending most of its time working on "off-main thread compositing" (OMTC) on the maple project branch. By separating Gecko into two threads, a content thread and a composition thread, we hope to make interacting with Firefox on Android more pleasant, because we won't be waiting on content to pan around pages.

When you pan to an area that hasn't been drawn yet, we display a "checkerboard" indicating that the content will be shown soon. Obviously, we want to minimize the time we display checkerboard to the minimum possible.

Here is the current breakdown of where we spend our time while panning around on cnn.com:

34.2%	painting
14.7%	waiting for texture upload to finish
12.2%	sleeping
8.2%	building display lists
3.4%	servicing timers
27.3%	other

Moving patches between git and hg

Moving patches between git and hg is currently not very easy. I found script that converts in one direction and I added script that goes in the other direction. The scripts are available here: https://github.com/jrmuizel/patch-converter. Hopefully, this will make it a bit easier.

WebGL considered harmful?

Today Microsoft posted an article titled "WebGL considered harmful". It seems like a lot of their arguments against WebGL also apply to Silverlight 5's XNA 3D graphics support. It, like WebGL, allows authors to write shaders using HLSL. I wonder, if you reframe their article by replacing WebGL with Silverlight 5, is anything untrue? If so, how does Microsoft solve these problems?

Silverlight XNA 3D considered harmful

Microsoft's Silverlight 5 XNA 3D technology is a low-level 3D graphics API for the web.

One of the functions of MSRC Engineering is to analyze various technologies in order to understand how they can potentially affect Microsoft products and customers. As part of this charter, we recently took a look at XNA 3D. Our analysis has led us to conclude that Microsoft products supporting XNA 3D would have difficulty passing Microsoft’s Security Development Lifecycle requirements. Some key concerns include:

• Browser support for Silverlight 5 directly exposes hardware functionality to the web in a way that we consider to be overly permissive
  The security of Silverlight 5 as a whole depends on lower levels of the system, including OEM drivers, upholding security guarantees they never really need to worry about before. Attacks that may have previously resulted only in local elevation of privilege may now result in remote compromise. While it may be possible to mitigate these risks to some extent, the large attack surface exposed by Silverlight 5 remains a concern. We expect to see bugs that exist only on certain platforms or with certain video cards, potentially facilitating targeted attacks.
  


• Browser support for Silverlight 5 security servicing responsibility relies too heavily on third parties to secure the web experience
  As Silverlight 5 vulnerabilities are uncovered, they will not always manifest in the Silverlight 5 API itself. The problems may exist in the various OEM and system components delivered by IHV’s. While it has been suggested that Silverlight 5 implementations may block the use of affected hardware configurations, this strategy does not seem to have been successfully put into use to address existing vulnerabilities.
It is our belief that as configurations are blocked, increasing levels of customer disruption may occur. Without an efficient security servicing model for video card drivers (eg: Windows Update), users may either choose to override the protection in order to use Silverlight 5 on their hardware, or remain insecure if a vulnerable configuration is not properly disabled. Users are not accustomed to ensuring they are up-to-date on the latest graphics card drivers, as would be required for them to have a secure web experience. In some cases where OEM graphics products are included with PCs, retail drivers are blocked from installing. OEMs often only update their drivers once per year, a reality that is just not compatible with the needs of a security update process.


• Problematic system DoS scenarios
  Modern operating systems and graphics infrastructure were never designed to fully defend against attacker-supplied shaders and geometry. Although mitigations such as Direct3D 10 may help, they have not proven themselves capable of comprehensively addressing the DoS threat. While traditionally client-side DoS is not a high severity threat, if this problem is not addressed holistically it will be possible for any web site to freeze or reboot systems at will. This is an issue for some important usage scenarios such as in critical infrastructure.

We believe that Silverlight 5 will likely become an ongoing source of hard-to-fix vulnerabilities. In its current form, XNA 3D in Silverlight 5 is not a technology Microsoft can endorse from a security perspective.

We recognize the need to provide solutions in this space however it is our goal that all such solutions are secure by design, secure by default, and secure in deployment.

The problems Microsoft is worried about are real, and they don't have any easy solutions. At the same, I don't think we need to wait for perfect answers before trying. With Silverlight 5's 3D support, it looks like Microsoft feels the same way.

WebP

Overall the reception to WebP that I've seen so far has been pretty negative. Jason Garrett-Glaser wrote a popular review, but there have been similar response from others like Charles Bloom. Since these reviews, the WebP encoder has improved on the example used by Jason (old vs. new) but it's still not a lot better than a decent JPEG encoding. I also have a couple of thoughts on the format that I'd like to share.

Google claims it's better than JPEG but this study has some problems and as a result, isn't very convincing (Update: Google has a new study that's better). First, they recompress existing JPEG's. This is unconventional. Perhaps recompressing JPEG's is their target market, but I find that a little weird and it should at least be explained in the study. Second, they use PSNR as a comparison metric. This is even more confusing. PSNR has, for a while now, been accepted as a poor measure of visual quality and I can't understand why Google continues to use it. I think it would help the format's credibility if Google did a study that used uncompressed source images, SSIM as a metric and provided enough information about the methodology so that others could reproduce their results.

WebP also comes across as half-baked. Currently, it only supports a subset of the features that JPEG has. It lacks support for any color representation other than 4:2:0 YCrCb. JPEG supports 4:4:4 as well as other color representations like CMYK. WebP also seems to lack support for EXIF data and ICC color profiles, both of which have be come quite important for photography. Further, it has yet to include any features missing from JPEG like alpha channel support. These features can still be added, but the longer they remain unspecified, the more difficult it will be to adopt.

JPEG XR provides a good example of what features you'd want from a replacement for JPEG. It has support for an alpha channel and HDR among others. Microsoft has also put in the effort to have it formally standardized. However, it too is not without problems. The compression improvements it claims haven't matched evaluations other parties have done. I don't know enough about JPEG XR to say whether this is because the encoders are bad or because the format is not really that great.

Every image format that becomes “part of the Web platform” exacts a cost for all time: all clients have to support that format forever, and there's also a cost for authors having to choose which format is best for them. This cost is no less for WebP than any other format because progressive decoding requires using a separate library instead of reusing the existing WebM decoder. This gives additional security risk but also eliminates much of the benefit of having bitstream compatibility with WebM. It makes me wonder, why not just change the bitstream so that it's more suitable for a still image codec? Given every format has a cost, if we're going to have a new image format for the Web we really need to make it the best we can make it with today's (royalty-free) technology.

Where does that leave us? WebP gives a subset of JPEG's functionality with more modern compression techniques and no additional IP risk to those already shipping WebM. I'm really not sure it's worth adding a new image format for that. Even if WebP was a clear winner in compression, large image hosts don't seem to care that much about image size. Flickr compresses their images at libjpeg quality of 96 and Facebook at 85: both quite a bit higher than the recommended 75 for “very good quality”. Neither of them optimize the huffman tables, which gives a lossless 4–7% improvement in size. Further, switching to progressive JPEG gives an even larger improvement of 8–20%.

History has shown that adoption of image formats on the internet is slow. JPEG 2000 has mostly failed on the internet. PNG took a very long time, despite having large advantages. I expect that adoption may even be slower now than it was in the past, because there is no driving force. I would also be surprised if Microsoft adopted WebP because of their stance on WebM and their involvment in JPEG XR. Can WebP succeed without being adopted by all of the major web browsers? It's hard to say, but it wouldn't be easy. Personally, I'd rather the effort being spent on WebP be spent on a improved JPEG encoder or even an improved JPEG XR encoder.

Is JPEG still great? No. Is there a great replacement for it? It doesn't feel like we're there yet.