On Fri, Dec 7, 2012 at 10:53 AM, Alexander Pavlov <[email protected]>wrote:
> On Fri, Dec 7, 2012 at 7:30 PM, Rick Byers <[email protected]> wrote: > >> On Thu, Dec 6, 2012 at 3:53 AM, Alexander Pavlov <[email protected]>wrote: >> >>> On Thu, Dec 6, 2012 at 12:24 PM, Adam Barth <[email protected]> wrote: >>> >>>> On Wed, Dec 5, 2012 at 10:44 PM, Alexander Pavlov <[email protected]> >>>> wrote: >>>> > On Thu, Dec 6, 2012 at 5:36 AM, Dana Jansens <[email protected]> >>>> wrote: >>>> >> On Wed, Dec 5, 2012 at 8:28 PM, Adam Barth <[email protected]> >>>> wrote: >>>> >> > On Wed, Dec 5, 2012 at 7:16 AM, Alexander Pavlov < >>>> [email protected]> >>>> >> > 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. >>> >> >> Are you sure this is what people want for testing purposes? When we were >> testing all our high-dpi chrome work before we had retina hardware, we >> wanted everything to be 2x bigger so we could spot low resolution images >> (which was the most common issue). If you use a 30" screen at twice the >> normal viewing distance, its basically the same as a real retina display. >> If you're scaling things back down again then many issues will not be >> visible. >> >> > > Our primary use case is testing the page layout and effective media > queries. We (our users, actually; see http://crbug.com/133590 with 26 > stars as of today) want to emulate a mobile device screen with all its > metrics, including the device pixel ratio. Screenshots in the said issue > explain what we have and what we want. DevTools can use lots of means to > inform users about the effects of the emulated DPR. E.g., display matched > CSS rules with associated media queries and show what resources from a > -webkit-image-set were actually transferred over the network. > Fair enough, as long as there's also some easy way to identify what scale factor each image has (maybe generate a warning or somehow highlight images whose scale factor is less than the DPR). Maybe these are two different issues. I'll post a comment to the bug. >>> >>>> >> >> 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 don't think a WebCore-only implementation will be very high quality. >>>> It might be a convenient hack, but it's not the right way to >>>> implement this feature. >>>> >>>> Based on what you've described, it sounds like you should use >>>> --force-device-scale-factor=2 and actually render to a 2x backing >>>> store. Then, once you've got the 2x backing store, you should >>>> downsample it to match the actual resolution of the monitor. I >>>> suspect we do something like that in the multimonitor case when a >>>> window is overlapping both a high density and a low density display. >>>> >>>> >>> Yes, I know this is THE right solution, but we have lots of requests >>> from DevTools users, so I've been looking for ways to implement the feature >>> on top of the existing and working code. >>> >>> >>>> > 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.) >>>> >>>> That might mean you should hold off on this feature until the >>>> compositor is able to support it. Hacking this into WebCore isn't >>>> going to produce a high quality implementation. >>>> >>> >>> Got it, thanks for consulting! >>> >>> -- >>> -alexander >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> [email protected] >>> http://lists.webkit.org/mailman/listinfo/webkit-dev >>> >>> >> > > > -- > -alexander >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
