Seems I can’t get enough of the IE7 ranting today!
This time, it’s to do with their new “Page Zoom” feature. Now, this is an awesome feature, and one that I’ve been hoping they’d implement in this release. One of the very cool things about this feature is that when you zoom in on an image, it uses a bicubic filtering to make the scaled image “smoother.”
Now, some people are complaining that they want to be able to switch to “nearest neighbour” scaling for development purposes, and I think that would be a useful feature as well. But that’s not what this rant is about.
You see, I run my laptop at 1920x1200 resolution (which is the screen’s native resolution). To make text readable, I also set my DPI to 144 (which is 150% of normal).
The great thing about CSS is that it was designed with resolution-independence in mind, which is why you can specify units as a percent, in points (pt), in em-units (em) or various other units. These units are great because it means the layout adjusts itself if the system is using a higher dots-per-inch than the “normal” 96DPI.
The problem was that CSS also included the “px” or “pixel” unit, which is directly related to pixels on the screen, and does not scale when the font size is increased. The problem is that millions of web developers running on 96DPI systems would use “px” to layout their pages, thinking that as long as it all looks right on their machine, then it’d be OK for everyone else, to. It was even worse if they mixed pixel-based sizes with point-based sizes.
Fortunately, IE6 came up with a brilliant solution to this problem, the UseHR registry key, which basically fools the website into thinking I’m running at 96DPI and just uniformly scales the whole thing up – images and all. In fact, this is the reason I use IE at home instead of Firefox.
It was awesome. The only problem I had with it, was that it always used the “nearest neighbour” algorithm for scaling images, which meant they looked a little “blocky” – especially since they were scaled 150% on my system, it meant that some pixels were twice as big, some were their original size.
I had high hopes that IE7 would fix that problem (I’d even considered on occasion writing a Browser Helper Object to do it for me (I would probably have had to hook the call to BitBlt and do the scaling myself or something). But it seems it has not. Well, not quite.
The problem, in my opinion is that their new “Page Zoom” feature just makes it a complete joke! Take a look at the following two images. The first was taken at 100% zoom, with UseHR turned on and 144DPI:
And here’s the same setup, but I used the Page Zoom feature to zoom to 99%:
You tell me which one is better... Now, it seems pretty obvious what they’ve done. For performance reasons, they’re calling the regular BitBlt when the zoom is 100% (which is what it would normally be) and only doing the (more expensive) bi-cubic filtering when you zoom.
Let’s hope this is a simple fix that’ll make it into the final release. After all, they should just have to change their condition to:
if (page-is-zoomed || UseHR)
{
// use bi-cubic filtering
}
else
{
// use normal BitBlt
}
Fingers crossed!
