Re: [webkit-dev] Possible device scale factor emulation approaches?
On Wed, Dec 5, 2012 at 10:44 PM, Alexander Pavlov apav...@chromium.org wrote: On Thu, Dec 6, 2012 at 5:36 AM, Dana Jansens dan...@chromium.org wrote: On Wed, Dec 5, 2012 at 8:28 PM, Adam Barth aba...@webkit.org wrote: On Wed, Dec 5, 2012 at 7:16 AM, Alexander Pavlov apav...@chromium.org wrote: I'm working on emulating the device scale factor with Web Inspector. My goal is to let web developers see their pages on normal (device pixel ratio == 1) monitors the way they would look on e.g. retina screens. Page::setDeviceScaleFactor() is not something we can use, since it will have the reverse effect when used by platform-specific compositor code (which I saw on Chromium, and its compositor is far from being ready for such abnormal treatment.) I'm not sure I fully understand what you're trying to accomplish. Is the developer using a high density screen or a low density screen? A low density screen is used (that's what I meant by normal (device pixel ratio == 1) monitors). Imagine two 24 monitors, one high-density (H) and one low-density (L), standing next to each other. I want any page to be rendered exactly the same both on H and L monitor. So, @media and image set elements should be chosen as if L monitor were H, but then the respective images/glyphs/whatever downscaled to match the visible size of the same items in the H monitor. I'm not sure I understand. L has fewer pixels than H. It's not clear how two things can render exactly the same given that they'll render using a different number of pixels. Chromium has a command line option for setting a fake device pixel ratio. For example, if you're using a low density screen, you can pass something like --device-pixel-ratio 2 to ask Chromium to render as if your device has a high density display. The net effect is that the glyphs get really big (since they use 2x the pixels in each dimension). Alternatively, I can imagine that the developer is using a high density screen but wants to develop a web site that looks good on a low density screen. In that case, they want to set a --device-pixel-ratio 1 but then render the web page pixel doubled (i.e., rasterizing each pixel as a 2x2 quad). I don't think there's a command line option for that in Chromium, but it's something you might reasonably do in the compositor. Naturally, but I would prefer not to touch the compositor code, as it is currently converging to the hardware-accelerated Ash implementation, and it's going to take a while until the dust settles down. That's not really a good reason to pick an inferior design. In general, though, trying to shim this feature into WebCore isn't likely the right approach. For WebKit2, for example, both the UI process and the web process need to agree about the device pixel ratio or else the system gets confused about how big various regions of memory ought to be. If you look at how we test high density rendering That's one reason why I do not want to fiddle with ACTUAL device pixel ratios (the same holds for the WebCore and compositor code in Chromium; the compositor code in desktop Chromium (non-Ash) is not ready to see anything other than 1 as device pixel ratio (WebViewImpl::setPageScaleFactor() has the following comment, Don't allow page scaling when compositor scaling is being used, as they are currently incompatible.)). What value do you want to return from window.devicePixelRatio? If you're going to return 1 on L but 2 on H, then the two are unlikely to render similarly as JavaScript on the page is likely to branch (or select subresources) based on that value. on low density machines, you'll see that we override the device's actual pixel density via the WebKit/WebKit2 API. That's to avoid this confusion. Yes, this is exactly my scenario - render pages on low-density (DPR==1) monitors as if they were high-density (DPR==2 or something else.) So, if the device's actual pixel density is overridden in WebKit/WebKit2, will glyphs and images get 2x bigger than those without the override? My goal is to have them visually remain the same size (because 1 CSS pixel should still correspond to 1 device pixel, as DPR==1 for low-density screens) along with the @media rules and -webkit-image-set elements (and perhaps some other things) appropriate for DPR==2 taking effect (downscaling larger 2x DPR images where applicable, so that they will look as if they were rendered on a high-density screen.) Do you think this can be emulated through the page settings, same was as the touch emulation (WebCore::Settings::setTouchEventEmulationEnabled()) instead? That's a super strange rendering mode. I took the approach of instrumenting the WebCore/css and WebCore/page code relying on the page-deviceScaleFactor() value. This worked pretty well, and you can see the respective patch at https://bugs.webkit.org/attachment.cgi?id=172046action=prettypatch
Re: [webkit-dev] Possible device scale factor emulation approaches?
On Thu, Dec 6, 2012 at 12:24 PM, Adam Barth aba...@webkit.org wrote: On Wed, Dec 5, 2012 at 10:44 PM, Alexander Pavlov apav...@chromium.org wrote: On Thu, Dec 6, 2012 at 5:36 AM, Dana Jansens dan...@chromium.org wrote: On Wed, Dec 5, 2012 at 8:28 PM, Adam Barth aba...@webkit.org wrote: On Wed, Dec 5, 2012 at 7:16 AM, Alexander Pavlov apav...@chromium.org wrote: I'm working on emulating the device scale factor with Web Inspector. My goal is to let web developers see their pages on normal (device pixel ratio == 1) monitors the way they would look on e.g. retina screens. Page::setDeviceScaleFactor() is not something we can use, since it will have the reverse effect when used by platform-specific compositor code (which I saw on Chromium, and its compositor is far from being ready for such abnormal treatment.) I'm not sure I fully understand what you're trying to accomplish. Is the developer using a high density screen or a low density screen? A low density screen is used (that's what I meant by normal (device pixel ratio == 1) monitors). Imagine two 24 monitors, one high-density (H) and one low-density (L), standing next to each other. I want any page to be rendered exactly the same both on H and L monitor. So, @media and image set elements should be chosen as if L monitor were H, but then the respective images/glyphs/whatever downscaled to match the visible size of the same items in the H monitor. I'm not sure I understand. L has fewer pixels than H. It's not clear how two things can render exactly the same given that they'll render using a different number of pixels. I mean the user-perceived image, where one L's pixel covers a square of four H's pixels. Naturally, but I would prefer not to touch the compositor code, as it is currently converging to the hardware-accelerated Ash implementation, and it's going to take a while until the dust settles down. That's not really a good reason to pick an inferior design. Agree. Assessing the design and picking the best approach was the original goal of my post. In general, though, trying to shim this feature into WebCore isn't likely the right approach. For WebKit2, for example, both the UI process and the web process need to agree about the device pixel ratio or else the system gets confused about how big various regions of memory ought to be. If you look at how we test high density rendering That's one reason why I do not want to fiddle with ACTUAL device pixel ratios (the same holds for the WebCore and compositor code in Chromium; the compositor code in desktop Chromium (non-Ash) is not ready to see anything other than 1 as device pixel ratio (WebViewImpl::setPageScaleFactor() has the following comment, Don't allow page scaling when compositor scaling is being used, as they are currently incompatible.)). What value do you want to return from window.devicePixelRatio? If you're going to return 1 on L but 2 on H, then the two are unlikely to render similarly as JavaScript on the page is likely to branch (or select subresources) based on that value. Right, so this should... or now, shouldn't, be instrumented, too... on low density machines, you'll see that we override the device's actual pixel density via the WebKit/WebKit2 API. That's to avoid this confusion. Yes, this is exactly my scenario - render pages on low-density (DPR==1) monitors as if they were high-density (DPR==2 or something else.) So, if the device's actual pixel density is overridden in WebKit/WebKit2, will glyphs and images get 2x bigger than those without the override? My goal is to have them visually remain the same size (because 1 CSS pixel should still correspond to 1 device pixel, as DPR==1 for low-density screens) along with the @media rules and -webkit-image-set elements (and perhaps some other things) appropriate for DPR==2 taking effect (downscaling larger 2x DPR images where applicable, so that they will look as if they were rendered on a high-density screen.) Do you think this can be emulated through the page settings, same was as the touch emulation (WebCore::Settings::setTouchEventEmulationEnabled()) instead? That's a super strange rendering mode. Well, it turned out to work well for me, since all layout was done using the correct DPR (corresponding to the device), but still, the resources and media queries chose the right resources/styles, so the page looked as if it were displayed on a retina. I took the approach of instrumenting the WebCore/css and WebCore/page code relying on the page-deviceScaleFactor() value. This worked pretty well, and you can see the respective patch at https://bugs.webkit.org/attachment.cgi?id=172046action=prettypatch (https://bugs.webkit.org/show_bug.cgi?id=100762), but now I'm wondering if there are better ways to implement this without
