Re: [webkit-dev] Device and page scaling
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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Device and page scaling
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
Re: [webkit-dev] Device and page scaling
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
Re: [webkit-dev] Device and page scaling
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
Re: [webkit-dev] Device and page scaling
On Tue, May 29, 2012 at 11:17 PM, Simon Fraser simon.fra...@apple.comwrote: 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. Interesting to hear that iOS does not yet use pageScaleFactor. Chrome for Android uses it heavily -- for gesture zooming, viewport tag and even deviceScaleFactor are applied using it (though we may reconsider the deviceScaleFactor part, since it means the viewport tag values don't correspond directly to pageScaleFactor values). However, we haven't been happy with how pageScaleFactor is applied asymmetrically depending on whether a layer is the root layer or not. On the root layer, the content bounds (and therefore scroll offset) are premultiplied by pageScaleFactor, allowing pixel-precise scroll offsets; however on all sublayers, the content bounds/scroll offsets stay locked into CSS coordinates. This leads to quite a few bugs, forked code, and general confusion. Do you know if iOS is more consistent here? If so, we could change pageScaleFactor to reflect iOS behavior, and allow them to converge on pageScaleFactor as well as fix some problems for Android. 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] build.webkit.org down for upgrade
to 0.8.6p1 Will be back online when complete. Lucas ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] build.webkit.org down for upgrade
Yay! for 0.8.6. Hopefully it fixes the stuck-in-trigger issue :) - Ryosuke On Wed, May 30, 2012 at 6:20 PM, Lucas Forschler lforsch...@apple.comwrote: to 0.8.6p1 Will be back online when complete. Lucas ___ 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
Re: [webkit-dev] Device and page scaling
On May 30, 2012, at 4:24 PM, John Mellor joh...@chromium.org wrote: 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. It seems to me that you could better address this use case by supporting fractional CSS pixels, which hopefully our new subpixel layout code can enable. The tricky thing about target-densityDpi=device-dpi is that it forces you to sniff the device pixel ratio and change pretty much all your layout based on it. If historically it would actually alter what is reported for devicePixelRatio, then it would be pretty hard to make a site design that looks right on both 1x and 2x devices with target-densityDpi=device-dpi. So I'm skeptical that anyone has made good use of it. 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. I guess that would be the right place to discuss dropping it from the spec, but it seems like here is the right place to discuss dropping it from the implementation. From comments in the CSS Device Adaptation spec, it seems like it was only added because it was in Android. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Removing type attribute from DOMSelection
Hi , We plan to remove the type attribute from DOM selection. This attribute is not part of any standard specification and the current webkit implementation is not consistent with IE. I looked at Firefox's selection interface and found its not implemeted there (http://doxygen.db48x.net/mozilla/html/interfacensISelection.html). The webkit bug is https://bugs.webkit.org/show_bug.cgi?id=23853 Please let me know, any concerns about removal of this attribute. Regards, -Antaryami ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Removing type attribute from DOMSelection
I support this proposal. While supporting the attribute itself does not impose much maintenance cost, the fact that our implementation is completely different from that of IE poses a serious compatibility problem. Also, there's an alternative to check each value of type that works on all modern browsers: none - getSelection().rangeCount() == 0 caret - getSelection().isCollapsed range - getSelection().rangeCount() !getSelection().isCollapsed - Ryosuke On Wed, May 30, 2012 at 9:58 PM, Antaryami Pandia xqb...@motorola.comwrote: We plan to remove the type attribute from DOM selection. This attribute is not part of any standard specification and the current webkit implementation is not consistent with IE. I looked at Firefox's selection interface and found its not implemeted there (http://doxygen.db48x.net/mozilla/html/interfacensISelection.html). The webkit bug is https://bugs.webkit.org/show_bug.cgi?id=23853 Please let me know, any concerns about removal of this attribute. Regards, -Antaryami ___ 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
