[webkit-dev] Device and page scaling

[Adam Barth]

On Wed, May 30, 2012 at 12:08 AM, Kenneth Rohde Christiansen
<kenneth.christiansen at 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.fraser at 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 ﹆﹆﹆