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.
<rdar://problem/15547943 >
<rdar://problem/15547943>
Created attachment 217841 [details] Patch
Note: I expect this will be controversial. I will not land it until there is some agreement. Review is fine though.
Patch is wrong - should navigate up to mainFrame.
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.
(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.
Created attachment 218142 [details] Patch
Updated patch after Brent's review. Weinig approved on IRC too. Leaving it here for 24 hours or so for anyone to complain.
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.
(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.
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
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?