On May 29, 2012, at 7:31 PM, Alexandre Elias <ael...@chromium.org> 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. By viewport do you mean the viewport meta tag? I don't think the Mac supports that, but it may be an interesting question for the iOS port. My guess would be that sizes in the viewport meta tag are scaled by the device pixel ratio, since our approach is that the same meta viewport should work in the same way on both Retina and non-Retina versions of the same device. Regards, Maciej > > > > On Tue, May 29, 2012 at 6:54 PM, Adam Barth <aba...@webkit.org> wrote: > There's a lot of confusion in the code base about how page and device > scaling works. Different ports are using Page::deviceScaleFactor for > incompatible purposes. On Mac, Page::deviceScaleFactor represents the > actual scaling factor of the physical device. It can change over time > because a given Page might be displayed on different devices over its > lifetime (e.g., if there are multiple monitors). On Chromium and Qt, > Page::deviceScaleFactor starts off as the actual scaling factor of the > physical device, but it can change over time if a web page has a > viewport meta tag that contains a target-densitydpi directive. > > There's also Settings::defaultDeviceScaleFactor, which represents the > actual scaling factor of the physical device on ports that adjust > Page::deviceScaleFactor based on the target-densitydpi directive. > Settings::defaultDeviceScaleFactor does not work on Mac (and can't > work because of multimon). > > Here's a proposal for making sense out of this mess: > > == Page::pageScaleFactor == > > Page::pageScaleFactor is a scaling factor that arises from the meta > viewport tag and from "pinch-to-zoom" interactions. This proposal > doesn't change anything about page scaling. > > == Page::deviceScaleFactor == > > Page::deviceScaleFactor is the scaling factor of the actual physical > device. It's value changes when the physical device displaying the > Page changes its scaling factor. It is not affected by > target-densitydpi or anything else unrelated to the physical device. > > == Page::effectiveDeviceScaleFactor == > > Page::effectiveDeviceScaleFactor starts off as matching > Page::deviceScaleFactor but changes to reflect any target-densitydpi > directives. It's unclear to me how Page::effectiveDeviceScaleFactor > should react when the underlying physical device changes its scaling > factor. Currently, that shouldn't occur, so I'm inclined to add an > ASSERT and worry about it later. > > == Settings::defaultDeviceScaleFactor == > > This variable will be deleted. > > Thoughts? > Adam > > _______________________________________________ > 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
