Eyes Above The Waves

Vlad and Stuart took off for the long weekend today after which they head back to Mountain View. It was fun hosting you guys! The office will be quiet again.

We did some Tp2 performance benchmarks with text in various configurations. On my Mac and the office Linux box, new-textframe seems to either have negligible impact or be a slight win. On Vlad's Vista laptop, it's a 5-10% slowdown. This is bad. I plan to look into this next week. Unfortunately when I tried to install Windows XP on the office box to get started on performance analysis, I realized that that box (an HP Proliant ML350) doesn't actually support Windows XP. That sucks. I'm going to have borrow Chris' laptop for a few days... (Ubuntu 7 had installed on it just fine, and it never crossed my mind Windows XP would have a problem with it. What a nightmare Windows installation/licensing/activation is...)

Earlier in the week I did some testing with my glyph bounds work-in-progress and found that on my Mac, performance impact was negligible using ATSUGetGlyphScreenBounds and my specialized glyph extents cache. That's probably another area where I'll need to do further performance analysis for Windows. Something to do after the new textframe is turned on.

In the meantime I've been fixing other random bugs, mostly various regressions from the new textframe.

We had an interesting discussion about text rasterization on Windows. There are basically three different high-quality rasterization schemes available, in increasing order of quality:

• Cleartype with "compatible widths". This is what GDI apps get by default on XP and Vista. "Compatible widths" means that Cleartype hinting isn't allowed to change glyph advances, so layouts are identical to what you'd get with Cleartype off. This is what we currently get.
  
• Cleartype with "natural widths". GDI apps can get this on Vista (but not XP, AFAIK) by setting some undocumented flag. This allows hinting to change glyph advances. We should definitely use this when available since Web apps don't get pixel-accurate layout compatibility anyway.
  
• WPF. This adds subpixel positioning and vertical subpixel antialiasing, and maybe other things. This doesn't seem to be available to GDI apps at all via published interfaces. We would like to use it but it's not clear how. We tossed around some crazy ideas, none of them appealing. Definitely not happening for 1.9.
  

On the bright side, on Mac we're getting subpixel positioning and antialiasing in all directions, so our cross-platform code is being tested for that already. If/when better rasterization becomes available we should be able to plug it right in.

In other news, Michael Ventnor has stepped up with a patch to fix some issues with GTK2 themes for HTML form controls and turn them on. We're going to try turning them on early in alpha6. We may revert the patch if there are major blocking issues that no-one steps up to fix. Now that Aqua form controls are on (nice work guys!), it would be nice to bring Linux/X up to speed too.

I finally landed the patch for getClientRects/getBoundingClientRect. This is a nice pair of DOM APIs that are mostly IE compatible, in the sense that elem.getBoundingClientRect().x/.y - document.body.getBoundingClientRect().x/.y should give you consistent results on IE and Firefox for elements that are descendants of the body (assuming the layouts are the same). The compatibility is limited in this way because we refuse to emulate some insane IE quirks regarding the body's reported position.

There's a bug about implementing document.elementFromPoint(x, y). This would be really easy to do if I wasn't swamped. It would be a good feature for someone new to come in and implement. It just needs to be added to the DOM IDL and implemented using the same display list machinery we use for event handling.