Adam's suggestions all sound sensible (making deviceScaleFactor based only on the physical device, deleting defultDeviceScaleFactor, and adding effectiveDeviceScaleFactor).
Adam Barth wrote: > It's unclear to me how Page::effectiveDeviceScaleFactor > should react when the underlying physical device changes its scaling > factor. We should just recompute it by calling dispatchViewportPropertiesDidChange on the ChromeClient. Dana Jansens wrote: > The other difference between ports or platforms is how > deviceScaleFactor is applied. It can be applied by being multiplied > into pageScaleFactor, or it could be applied separately as a > post-processing/compositing property, or potentially other ways. Did > you have thoughts on that? You say pageScaleFactor is unchanged, > but I think it would be nice to separate these two things more > distinctly, then combine them more explicitly where appropriate. It doesn't make sense to always scale output by deviceScaleFactor (for example when viewing a desktop page on mobile the deviceScaleFactor isn't really relevant). Instead it's primary purpose is just as input to the computeViewportAttributes calculation to help resolve the meaning of device-width, through which it affects the default pageScaleFactor. And this way you only have one real scale factor to worry about: pageScaleFactor, which always gives you the ratio of screen to CSS pixels. Maciej Stachowiak wrote: > Can you explain why the target-densitydpi feature even exists? It > seems ill-conceived to me, and the most straightforward fix would > be to remove it. I have not heard anyone explain the use case for > it. (I'm also not clear on the details of what it actually does, and > neither the name nor the docs are enlightening.) Designers who insist on pixel-perfect rendering can use "width=device-width, target-densityDpi=device-dpi" to make their site render at one CSS pixel per screen pixel, letting you get crisp non-scaled borders etc. It does however require the designer to manually adjust dimensions and font-sizes to compensate for the dpi using window.devicePixelRatio, which is incredibly onerous (especially in a cross-platform design, which must look the same on devices that don't support target-densityDpi, hence everything needs to be implemented twice). That's the main use case, though it's pretty niche (if you want pixel-perfect UI, it's generally less hassle to just use high resolution images and scale them down). The other values I don't know of any compelling use cases for; I'll talk to the engineer who first added this and see if they have any good ones. I don't know whether or not we can remove it (would need to check how popular it is), but it might be possible to deprecate it (recommend against using it). That's probably something we should discuss on www-style rather than here. Cheers, John On Wed, May 30, 2012 at 8:08 AM, Kenneth Rohde Christiansen < kenneth.christian...@gmail.com> wrote: > 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 >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
