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. > 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. > > 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.")). > > 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? > >> 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=172046&action=prettypatch > >> (https://bugs.webkit.org/show_bug.cgi?id=100762), but now I'm > wondering if > >> there are better ways to implement this without instrumenting lots of > >> page->deviceScaleFactor() call sites. > >> > >> Comments, ideas, suggestions, please? > > > > If you want to see how this is done in Chromium, you might want to > > study the --device-pixel-ratio command line flag. In general, I don't > > think you want to try to implementing this feature by hacking WebCore > > as it requires coordination beyond WebCore to do correctly. > What if I try implementing this in a way that does not require any coordination beyond WebCore? I mean, overriding everything Web-related only in WebCore, but without requiring anything on the platform-specific part. > I think Adam is refering to the --force-device-scale-factor=2 flag for > chromium. To try it out, you may need to build with the use_ash=1 > flag. > I've been in touch with aelias for over half a year, and his latest advice was to abstain from using this flag (or modifying page->setDeviceScaleFactor(), or touching the compositor :-) ) on something other than Ash for at least a few quarters more, until the Chromium compositor code converges to the implementation used by Ash (that's what I implied by saying that "its compositor is far from being ready for such abnormal treatment"). Until then, event-handling code will still handle physical rather than emulated mouse pointer coordinates, so the page interaction will be completely broken, and you will see lots of noise/garbage rendered where inapplicable.) -- -alexander
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
