Hi, I don't think we are doing that much differently.
Desktop Safari is scaling directly in WebCore using the pageScaleFactor whereas Qt like iOS scales outside of WebCore (using a tiled backing store), resulting in the FrameView not being in UI pixels. devicePixelRatio currently can become 1 on some viewport meta tag cases in Qt (/Chromium), but I am already convinced that we should remove the code doing this, which would basically solve most of our differences in behavior. Cheers, Kenneth On Wed, May 30, 2012 at 8:17 AM, Simon Fraser <simon.fra...@apple.com> wrote: > On May 29, 2012, at 7:31 PM, Alexandre Elias wrote: > >> Thanks for looking into this, I like this naming scheme and Chrome for >> Android would be willing to switch to it. >> >> Another major semantic question is how deviceScaleFactor relates to the >> FrameView viewport size. Currently on Chrome for Android and Qt ports, the >> viewport is just the physical pixel size, whereas on ChromeOS it's >> pre-divided by deviceScaleFactor (passed in that way by the embedder -- the >> whole UI is device-scale-independent there). >> >> I don't know what the Mac Safari port does and would be very interested to >> hear. If the Mac port behaves like ChromeOS here and there is no intention >> to switch to the other approach, we may unfortunately have to introduce yet >> another variable to represent the split in behaviors; otherwise ChromeOS can >> adjust its viewport size to converge with all other ports. > > On Mac and iOS, deviceScaleFactor exactly matches window.devicePixelRatio, > and is simply a measure of how many physical pixels correspond to each "UI" > pixel on the device: 1 for normal displays, and 2 for Retina displays on > relevant iOS devices. Theoretically these could change if a window moves > between displays, but are independent of user scaling. > > All FrameView/viewport sizes etc are in "UI" pixels, and are not affected by > deviceScaleFactor. This sounds like the ChromeOS way, which is preferable to > the Android/Qt way by the sound of it. > > Gesture zooming on Mac (not to be confused with CSS zoom/text zooming) > affects pageScaleFactor, but this is independent of deviceScaleFactor. On > Mac, pageScaleFactor is implemented via a RenderStyle transform on the > RenderView's RenderLayer. Mac doesn't support the viewport meta tag. > > On iOS, zooming is mostly done outside of WebKit. The viewport tag affects > page scale in the same way that user zooming does. iOS has its own zoom > factor plumbed into WebCore, but ideally would share pageScaleFactor. On iOS, > zooming used to not affect "client" coordinates (getBoundingClientRects, > event clientX/clientY etc), but gradually iOS has migrated to a model were > client coords are relative to the "porthole" viewport (which is not the same > as the CSS viewport). Panning on iOS happens outside of WebKit, and is not > equivalent to FrameView scrolling, but some notion of the page offset is > plumbed through to update scrollTop, and for scroll events etc. > > This is a tricky area to get right, especially since different ports have > their own notions of zooming, panning etc. It's going to be a challenge to > get all ports sharing code here. > > Simon > -- Kenneth Rohde Christiansen Senior Engineer Nokia Mobile Phones, Browser / WebKit team Phone +45 4093 0598 / E-mail kenneth at webkit.org http://codeposts.blogspot.com ﹆﹆﹆ _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
