[webkit-dev] Possible device scale factor emulation approaches?

Rick Byers rbyers at chromium.org
Fri Dec 7 08:03:47 PST 2012 

On Fri, Dec 7, 2012 at 10:53 AM, Alexander Pavlov <apavlov at chromium.org>wrote:

> On Fri, Dec 7, 2012 at 7:30 PM, Rick Byers <rbyers at chromium.org> wrote:
>
>> On Thu, Dec 6, 2012 at 3:53 AM, Alexander Pavlov <apavlov at chromium.org>wrote:
>>
>>>  On Thu, Dec 6, 2012 at 12:24 PM, Adam Barth <abarth at webkit.org> wrote:
>>>
>>>> On Wed, Dec 5, 2012 at 10:44 PM, Alexander Pavlov <apavlov at chromium.org>
>>>> wrote:
>>>> > On Thu, Dec 6, 2012 at 5:36 AM, Dana Jansens <danakj at chromium.org>
>>>> wrote:
>>>> >> On Wed, Dec 5, 2012 at 8:28 PM, Adam Barth <abarth at webkit.org>
>>>> wrote:
>>>> >> > On Wed, Dec 5, 2012 at 7:16 AM, Alexander Pavlov <
>>>> apavlov at 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.
>>>
>>
>> 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
>>> webkit-dev at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>>
>>
>
>
> --
> -alexander
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20121207/631d4ec4/attachment.html>

More information about the webkit-dev mailing list