Bug 124862 – Expose a way to detect page zoom

• Component: DOM
• Status: NEW

[Dean Jackson]

There is a discussion underway in various places about what devicePixelRatio should mean.

Apple always intended this to be the *constant* mapping between CSS px and device pixels at uniform zoom. i.e. it is 2 on a "retina" device.

Other browsers appear to have started including page zoom in that calculation, making devicePixelRatio = pageZoom * pixels-per-css-px-at-uniform-scale. Problems:

1. We know there is existing content that is expecting a retina device to have a devicePixelRatio of 2. We don't want to break that.
2. Some developers may want to detect pageZoom separately
3. Merging devicePixelRatio this way can cause rounding errors
4. Many of the use cases for the merge mention sizing canvas elements, but developers might not want their canvas to respond to pageZoom.

For this reason I suggest we expose page zoom next to (our) devicePixelRatio. This would allow developers to get the same answer as other browsers, if that's what they want.

[Dean Jackson]

<rdar://problem/15547943
>

[Dean Jackson]

<rdar://problem/15547943>

[Dean Jackson]

Created attachment 217841 [details]
Patch

[Dean Jackson]

Note: I expect this will be controversial. I will not land it until there is some agreement. Review is fine though.

[Dean Jackson]

Patch is wrong - should navigate up to mainFrame.

[Brent Fulgham]

Comment on attachment 217841 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=217841&action=review

Seems pretty straightforward to me.  r=me, whenever you want to land it.

> Source/WebCore/page/DOMWindow.h:233
> +        double webkitPageZoomRatio() const;

Should we bother calling this "webkitPageZoomRatio" here? I think it make sense to expose this to users with a webkit-prefix, but here in the guts of WebKit it seems redundant.

[Dean Jackson]

(In reply to comment #6)
> (From update of attachment 217841 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=217841&action=review
> 
> Seems pretty straightforward to me.  r=me, whenever you want to land it.
> 
> > Source/WebCore/page/DOMWindow.h:233
> > +        double webkitPageZoomRatio() const;
> 
> Should we bother calling this "webkitPageZoomRatio" here? I think it make sense to expose this to users with a webkit-prefix, but here in the guts of WebKit it seems redundant.

Good point. I'll change this.

[Dean Jackson]

Created attachment 218142 [details]
Patch

[Dean Jackson]

Updated patch after Brent's review. Weinig approved on IRC too. Leaving it here for 24 hours or so for anyone to complain.

[Simon Fraser (smfr)]

Comment on attachment 217841 [details]
Patch

I don't think we should do this until there's some amount of consensus amount browser vendors, otherwise we may end up with an orphaned property name.

[Dean Jackson]

(In reply to comment #10)
> (From update of attachment 217841 [details])
> I don't think we should do this until there's some amount of consensus amount browser vendors, otherwise we may end up with an orphaned property name.

The problem is that the other vendors don't want to change (and neither do we unless we have to). At the moment there is no way to get the same value as other browsers in WebKit, since we don't expose page zoom.

[Gregg Tavares]

Are the arguments for why WebKit does not want to expose zoom detailed somewhere? Has it been reconsidered in the 7 years since this issue was posted?

As a graphics programmer I want Canvas to be just as useful as SVG. Without zoom I can't do that.

Here's an example that uses devicePixelRatio to adjust the rendering of a canvas to match the zoom level. 

https://jsgist.org/embed.html?src=09d9815bf187d5f93541c100f0fb9a78

In Chrome/Edge/Firefox it's possible 

https://i.imgur.com/QN8varG.png


But in Safari it's not

https://i.imgur.com/GjiOoMS.png

[Gregg Tavares]

It would be nice to get some response from Apple on this 8yr old bug.

There are other issues here. For example, the majority of WebGL pages (like for example most of the ones on this page, https://threejs.org/examples/, a canvas that covers the page. They adjust the resolution of the canvas like this

    canvas.width  = canvas.clientWidth  * devicePixelRatio
    canvas.height = canvas.clientHeight * devicePixelRatio

On Chrome and Firefox, because the devicePixelRatio changes based on the zoom level, when zooming out, this means the statement ends up with the canvas staying the same resolution.  But on Safari, because devicePixelRatio does not change, the resolution becomes extreme,

See this example:

https://greggman.github.io/doodles/test/canvas-backing-resize/canvas-backing-resize.html

On my 38inch monitor with a fullscreen window in Chrome on MacOS 12 at zoom level 100% I get 

                dpr: 2
              width: 6304
             height: 2392
 drawingBufferWidth: 6304
drawingBufferHeight: 2392
  min memory needed: 361.9m

If zoom out to 25% I get

                dpr: 0.6666666865348816
              width: 6304.00018787384
             height: 2392.000071287155
 drawingBufferWidth: 6304
drawingBufferHeight: 2392
  min memory needed: 361.9m

But in Safari at 100%

                dpr: 2
              width: 6304
             height: 2512
 drawingBufferWidth: 6304
drawingBufferHeight: 2512
  min memory needed: 380.1m

And zoomed out to 25%

                dpr: 2
              width: 12608
             height: 5024
 drawingBufferWidth: 12608
drawingBufferHeight: 5024
  min memory needed: 1.5g

Because devicePixelRatio is not changing in Safari the page ends up allocating 1.5gig of vram since it has no way to know it doesn't really end a 12608x5024 canvas. It also means Safari has a significant per issue for most WebGL apps if the user zooms out.

Further, AFAIK devicePixelRatio is supposed to be the mapping of CSS pixels to device pixels so it certainly makes sense that it change in response to zooming  since the number of device pixels to css pixels is actually changing.

Given that Chrome and Firefox have been shipping this way for over 8yrs and so developers are used to this is there any chance that WebKit/Safari will consider supporting this feature?

[Keavon]

It's disappointing that this bug is still not resolved. Display scaling seems rather fundamental for web apps hoping to offer a good experience, especially on Retina displays.