[Webkit-unassigned] [Bug 14998] Full page zooming support

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=14998





------- Comment #24 from darin at apple.com  2007-09-27 15:31 PDT -------
(From update of attachment 16413)
I think the naming of variables is a little weak. For example "event" is the
event without scaling applied, and "mouseEvent" is the event with scaling
applied. The names should make more clearly what's going on. In particular,
what's happening is that we're converting the x/y coordinates from viewport
coordinates to scaled viewport coordinates. But I also think it would be more
logical to do the scaling when converting from viewport coordinates to document
coordinates.

I also think it's a little weak to make an entire copy of the event in cases
like this -- since the only thing affected is the x/y coordinates. This will
cause a disconnect between the original event object and the new one; for
example the scaled mouse event won't have the correct event number (on
Macintosh). We should come up with a better design that separates the scaled
X/Y from the rest of the event or allows you to change the X/Y in an event or
something along those lines.

It's bad to override a non-virtual function FrameView::resize -- for one thing
there are two overloads of resize and one takes an IntSize. For another it's
almost never a good idea to override a non-virtual function. I'd like to see a
clearer set of rules about which parameters are which kinds of coordinates.

The Page::setScaleFactor function should do more than just set the new scale
factor value. Like Frame::setZoomFactor (that function has a terrible name and
place!) it should trigger the appropriate layout and painting.

The patch seems to have some Cairo things not directly related to the arbitrary
zooming; lets land those separately.

High level code should almost never be explicitly multiplying by the scale
factor. The correct primitives are to change coordinates from document space to
viewport space. So PlatformScrollbar::geometryChanged should not need to
multiply by the scale factor. I think contentsToWindow might be the function we
want to modify, or something along those lines.

One problem I see is that on Mac we have arbitrary transforms on WebView, but
currently they don't work properly; if I was doing a patch, I'd do the
cross-platform code that handles things like mouse events in a way that could
work for that as well. The code should be based on the concept of an arbitrary
transform even if what's stored is simply a scale factor.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.