On Wed, May 30, 2012 at 12:08 AM, Kenneth Rohde Christiansen <kenneth.christian...@gmail.com> wrote: > 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.
This doesn't match what Simon Fraser wrote. He said that all FrameView sizes on iOS are in "UI" pixels. Adam > 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
