NEW 124862
Expose a way to detect page zoom
https://bugs.webkit.org/show_bug.cgi?id=124862
Summary Expose a way to detect page zoom
Dean Jackson
Reported Monday, November 25, 2013 10:54:58 PM UTC
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.
Attachments
Patch (5.72 KB, patch)
2013-11-25 15:37 PST, Dean Jackson
bfulgham: review+
bfulgham: commit-queue-
Patch (5.71 KB, patch)
2013-12-01 22:09 PST, Dean Jackson
no flags
Dean Jackson
Comment 1 Monday, November 25, 2013 11:00:39 PM UTC
Dean Jackson
Comment 2 Monday, November 25, 2013 11:01:22 PM UTC
Dean Jackson
Comment 3 Monday, November 25, 2013 11:37:59 PM UTC
Dean Jackson
Comment 4 Monday, November 25, 2013 11:39:06 PM UTC
Note: I expect this will be controversial. I will not land it until there is some agreement. Review is fine though.
Dean Jackson
Comment 5 Tuesday, November 26, 2013 8:28:41 PM UTC
Patch is wrong - should navigate up to mainFrame.
Brent Fulgham
Comment 6 Wednesday, November 27, 2013 3:15:34 AM UTC
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
Comment 7 Friday, November 29, 2013 8:16:47 PM UTC
(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
Comment 8 Monday, December 2, 2013 6:09:01 AM UTC
Dean Jackson
Comment 9 Monday, December 2, 2013 6:09:46 AM UTC
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 10 Monday, December 2, 2013 7:02:41 PM UTC
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
Comment 11 Monday, December 2, 2013 9:23:02 PM UTC
(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
Comment 12 Friday, January 8, 2021 6:00:33 AM UTC
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
Comment 13 Wednesday, February 9, 2022 5:52:12 PM UTC
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
Comment 14 Saturday, January 25, 2025 8:45:08 AM UTC
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.
Note You need to log in before you can comment on or make changes to this bug.