Eyes Above The Waves

Robert O'Callahan. Christian. Repatriate Kiwi. Hacker.

Friday 19 October 2007

A Tale Of Two Zooms

Daniel Glazman is concerned about the behaviour of our zoom implementation. In particular he's bothered by the fact that zooming can change the layout of a page.

This is intentional. There are actually two ways you can implement zooming:


  1. Just scale everything by the zoom factor when drawing, and leave the page layout unchanged. This is what Daniel wants.
  2. Try make the page look as good as possible when zooming, by changing the layout as necessary. This is what we have implemented.

One key difference between the approaches is the way text hinting is handled. When you draw text at a certain size, a good font engine will "hint" the glyphs, e.g. make sure that the vertical lines of an "n" are aligned on pixel boundaries, and this can change glyph metrics. For example, the width of a hinted "n" in 20pt is not necessarily twice the width of "n" in 10pt. So, if we want text to look its best, we must allow the advance width of text to change non-linearly when we change the zoom factor, and that can change layout in arbitrary ways. If we insist on preserving layout, we have to have to use unnatural glyph advance widths, which can't look as good.

Another difference is the handling of native widgets. They may not look good or work well when scaled to odd sizes, so we might not scale them or scale them differently, if we're free to modify the layout.

Another difference is how the available width is handled. If you insist on preserving layout when zooming in, you will almost always force the user to scroll horizontally to see all the content, or when zooming out in a desktop browser, the full width of the window will not be used.

Furthermore as a practical matter we currently have no foolproof way to scale rendering of plugins without actually changing their size, so we can't implement approach 1 for plugins.

For all these reasons I think exposing the second zooming approach in the Firefox 3 UI is the right way to go.

However, Daniel is absolutely right to point out that this is not what you want for a "zoom out and pan" UI in a mobile browser --- or a "magnifying glass" UI, for that matter! For those, it is important to preserve layout. Fortunately, implementing them is easy in principle, now that we're based on cairo; just scale the transform when drawing. There are a few problems, such as handling plugin rendering as I mentioned, but those can be hacked around or fixed. Some work would need to be done to expose this zoom mode as an additional prescontext/presshell API. I'm sure that in the future we'll offer both modes (to embedders and XUL apps, if not to Firefox users). (You can actually mock up this approach today by embedding an <iframe> in an SVG <foreignobject> and scaling that, although there are some problems.)



Comments

Sjoerd Visscher
IE has approach 1, which makes zooming in in IE useless.
Approach 2 is much better, but you could argue that you shouldn't call it zoom.
Anonymous
Does Opera use zoom type 1 or 2 as its only zoom model? Whatever they use seems pretty useful to me.
What's not useful about IE zooming? As someone with less than perfect eyesight, I've found both IE and Opera zooming useful. As a Web designer, the value of zooming goes down as the number of items which don't zoom in "magnifying glass" style increases.
I was hoping that once IE and Firefox supporting "true" zooming, that the days of having to worry about layouts breaking because of text scaling would be behind us. Type 2 zooming just sounds like the problem continues.
My vote is for Type 1 zooming. If you want something else, implement it as a separate option. There is a bug in the system for "Opera-like zooming". If Type 2 zoom is what you'll be providing, I hope the bug will remain open as you seem to have solved a different problem.
Robert O'Callahan
I'm not sure but I believe Opera uses type 2 zooming.
> the days of having to worry about layouts
> breaking because of text scaling would be behind
> us. Type 2 zooming just sounds like the problem
> continues.
I don't think so. All objects are scaled, so layout is mostly preserved --- a lot more so than with text zoom --- just not perfectly.
voracity
I agree completely with the 2 types and the situations in which you'd use them. I'm guessing people using desktop browsers would want type 2 (content zooming) more than 95% of the time. I'm guessing type 1 (snapshot zooming) would only be wanted when you aren't actually interested in interacting with the page (like with thumbnails or zoom and pan) but want a live scaled version of exactly what you will get when you go back to the normal zoom.
"[Native widgets] may not look good or work well when scaled to odd sizes, so we might not scale them or scale them differently, if we're free to modify the layout."
But the scaling of form controls in Daniel's content-zooming screenshot is a bug, yes? Are there plans to fix that problem by the time Firefox 3 is released?
Robert O'Callahan
It's arguably a bug. I don't think it's a priority to fix in Firefox 3 because we don't expect users to be zooming far out.
Ollie
This is tricky because there are two problems to tackle: display resolution and display size. These two factors are independent.
Flexible layout and font sizes will generally be the ideal response to a display that is too small - while increasingly 'zooming' everything will help when the resolution is too high. It all depends... on content and context.