ThecanvasResolution
attribute of theScreen
object must return the pixel density, in image pixels per coordinate space units, that anycanvas
andCanvasRenderingContext2D
bitmaps created during this task will use (or have used). [1]
--
http://annevankesteren.nl/
window.screen.canvasResolution
implies that it is a constant.Returns the pixel density that has been, or will be, used for bitmaps during this task.
Primary eng/PM emails
e...@chromium.org
Spec
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-screen-canvasresolution
On Wed, Jul 3, 2013 at 4:09 PM, Adam Barth <aba...@chromium.org> wrote:I wouldn't call it nitch something like 10% of page views are zoomed
> Page zoom is such a nitch feature... How do we plan to assess the
> compatibility impact of changing the semantics of devicePixelRatio during a
> page zoom?
(looking at gmail data)
and knowing the ratio for css to device pixels
is quite important for pages/apps like maps and docs. I really don't
care about _how_ we expose the css:device ratio but we really do need
to expose it somehow, be it through devicePixelRatio,
canvasResolution, logicalXDPI or some other way.
On Wed, Jul 3, 2013 at 3:47 PM, Emil A Eklund <e...@chromium.org> wrote:
The use case is to allow an appropriate resource to be loaded for
canvas and images. Recent discussion seems to have converged on
updating devicePixelRatio on zoom instead and if we can agree on that
then this property would no longer be needed. I'll obviously hold of
implementing this until a consensus has been reached and would gladly
implement the devicePixelRatio changes instead if that turns out to be
the way forward.
See https://code.google.com/p/chromium/issues/detail?id=177836 for details.
I'm skeptical about dynamically changing the devicePixelRatio while a page is rendering. That's not something pages need to handle today, and I'd expect many to break in weird and wonderful ways. I also suspect that many pages won't work properly if devicePixelRatio takes on a value other than 1 or 2.
On Wed, Jul 3, 2013 at 4:09 PM, Adam Barth <aba...@chromium.org> wrote:
On Wed, Jul 3, 2013 at 3:47 PM, Emil A Eklund <e...@chromium.org> wrote:
The use case is to allow an appropriate resource to be loaded for
canvas and images. Recent discussion seems to have converged on
updating devicePixelRatio on zoom instead and if we can agree on that
then this property would no longer be needed. I'll obviously hold of
implementing this until a consensus has been reached and would gladly
implement the devicePixelRatio changes instead if that turns out to be
the way forward.
See https://code.google.com/p/chromium/issues/detail?id=177836 for details.
I'm skeptical about dynamically changing the devicePixelRatio while a page is rendering. That's not something pages need to handle today, and I'd expect many to break in weird and wonderful ways. I also suspect that many pages won't work properly if devicePixelRatio takes on a value other than 1 or 2.The devicePixelRatio can be 1.4, 1.5, 1.8 and probably other values on currently shipping devices. Several Android devices have scales in the 1.5 range and Windows 8 supports 1.4/1.8.
On Wed, Jul 3, 2013 at 3:47 PM, Emil A Eklund <e...@chromium.org> wrote:The use case is to allow an appropriate resource to be loaded for
canvas and images. Recent discussion seems to have converged on
updating devicePixelRatio on zoom instead and if we can agree on that
then this property would no longer be needed. I'll obviously hold of
implementing this until a consensus has been reached and would gladly
implement the devicePixelRatio changes instead if that turns out to be
the way forward.
See https://code.google.com/p/chromium/issues/detail?id=177836 for details.
I'm skeptical about dynamically changing the devicePixelRatio while a page is rendering. That's not something pages need to handle today, and I'd expect many to break in weird and wonderful ways.
Adam wrote:
> I'm skeptical about dynamically changing the devicePixelRatio while
> a page is rendering. That's not something pages need to handle
> today, and I'd expect many to break in weird and wonderful ways.
Yes, that is my only concern. I see two paths:
A) Ideal but risky: after testing (somehow) whether sites break if devicePixelRatio changes, if we determine that this isn't a problem then go ahead and make it directly linked to the page zoom factor (and update as much documentation as possible to mention this).
B) The safer option: when the page loads, if full page zoom is persisted for that domain then incorporate the stored page zoom factor into the devicePixelRatio, but don't update the devicePixelRatio if the page zoom factor changes while the page is open. If there are enough sites that do care about full page zoom, we could provide an additional liveDevicePixelRatio property (better names please!) which would update as in A.
I'm ambivalent whether we go for A or B.
Rik wrote:
> Yes, please don't make devicePixelRatio. Not only will you
> break content, on large ratio's you might cause the browser to make
> huge allocations if people multiply the devicePixelRatio with width and
> height.
Huge allocations shouldn't be a problem here. Remember that with full page zoom, we first divide the viewport width by the page zoom factor, so if the page scales textures up by the page zoom factor (via devicePixelRatio), they'll just end up with the same size they would have had if the page wasn't zoomed.
Rik wrote:
> I doubt many page optimize for the opera case so they are most likely
> broken (in that they won't update on opera as the user zooms in/out)
That's not broken, that's reasonable behaviour. But worse cases are certainly possible, as discussed in my reply to Adam.
James wrote:
> The devicePixelRatio can be 1.4, 1.5, 1.8 and probably other values on
> currently shipping devices.
1.33x (Nexus 7) and 3x (Samsung Galaxy S4) are also common.
Adam wrote:
> I'm skeptical about dynamically changing the devicePixelRatio while
> a page is rendering. That's not something pages need to handle
> today, and I'd expect many to break in weird and wonderful ways.Yes, that is my only concern. I see two paths:
A) Ideal but risky: after testing (somehow) whether sites break if devicePixelRatio changes, if we determine that this isn't a problem then go ahead and make it directly linked to the page zoom factor (and update as much documentation as possible to mention this).
B) The safer option: when the page loads, if full page zoom is persisted for that domain then incorporate the stored page zoom factor into the devicePixelRatio, but don't update the devicePixelRatio if the page zoom factor changes while the page is open. If there are enough sites that do care about full page zoom, we could provide an additional liveDevicePixelRatio property (better names please!) which would update as in A.
I'm ambivalent whether we go for A or B.
Rik wrote:
> Yes, please don't make devicePixelRatio. Not only will you
> break content, on large ratio's you might cause the browser to make
> huge allocations if people multiply the devicePixelRatio with width and
> height.Huge allocations shouldn't be a problem here. Remember that with full page zoom, we first divide the viewport width by the page zoom factor, so if the page scales textures up by the page zoom factor (via devicePixelRatio), they'll just end up with the same size they would have had if the page wasn't zoomed.
If you have a 1024x768 2d canvas on a 1024x768 device and you zoom in to 1000%, doesn't that make the backing store for the canvas 100 times bigger?
What type of 'zoom' are we trying to detect? Is it using the ctrl-+/- or using gestures on a tablet?There's a thread on devicePixelRatio on www-style: http://lists.w3.org/Archives/Public/www-style/2012Nov/0144.htmlctrl-+/- causes layout so changes devicePixelRatio but zooming does not.
On Thu, Jul 4, 2013 at 9:19 AM, Rik Cabanier <caba...@gmail.com> wrote:What type of 'zoom' are we trying to detect? Is it using the ctrl-+/- or using gestures on a tablet?There's a thread on devicePixelRatio on www-style: http://lists.w3.org/Archives/Public/www-style/2012Nov/0144.htmlctrl-+/- causes layout so changes devicePixelRatio but zooming does not.Page zoom = control +/-Page scale = pinch gesturesAIUI, page zoom is the only thing being discussed here.
If you tie the two together, things would get blurry in the zoom in case (not what the user wants) and crash the machine in the zoom out case (we've had to work around this in Maps already because creating >4kx4k canvas backing stores would hard lock OSX and crash browsers on other platforms).
This thread seems to have slowed down, but I want to point out that changing devicePixelRatio is absolutely not what we want for Maps.For Maps, we size our labels in CSS pixels so that they're the same physical size on retina or normal devices. That is, the size of a label is independent of devicePixelRatio.When the user zooms the browser, the text on the page changes, except for on-map labels! We need tobe able to detect browser zoom separately from devicePixelRatio to be able to give the user a good experience.
This thread seems to have slowed down, but I want to point out that changing devicePixelRatio is absolutely not what we want for Maps.
For Maps, we size our labels in CSS pixels so that they're the same physical size on retina or normal devices. That is, the size of a label is independent of devicePixelRatio.
When the user zooms the browser, the text on the page changes, except for on-map labels! We need tobe able to detect browser zoom separately from devicePixelRatio to be able to give the user a good experience.
Likewise, zooming the browser should make the existing map tiles bigger or smaller, not change the number of tiles on the screen, which is what changing devicePixelRatio would do.
To provide a consistent experience to users, we need to know the zoom of the browser, and to be able to distinguish it from the native DPI of the device.
Can you explain more of the "why" behind this statement? To be clear, we're talking about Ctrl-+/- (i.e., "full-page zoom") rather than the pinch-to-zoom feature of touch interfaces (i.e., page scale). Typically, when the user uses Ctrl-+, everything on the page occupies more physical space on their monitor, including buttons and labels. What does change, for example, are rounded corners, which have larger radii but smoother curves.
For maps, I would expect Ctrl-+ to make all the text larger (including labels---I likely used Ctrl-+ because I have difficulty reading small type) but to be able to see more detailed coastlines (similar to how rounded corners are smoother).
James, I'm still digesting your mail and will respond. You might be right, my objections might not be correct.On Tue, Jul 9, 2013 at 2:45 PM, Adam Barth <aba...@chromium.org> wrote:Can you explain more of the "why" behind this statement? To be clear, we're talking about Ctrl-+/- (i.e., "full-page zoom") rather than the pinch-to-zoom feature of touch interfaces (i.e., page scale). Typically, when the user uses Ctrl-+, everything on the page occupies more physical space on their monitor, including buttons and labels. What does change, for example, are rounded corners, which have larger radii but smoother curves.Today pinch-to-zoom and Ctrl-+/- do the same thing, yes? They show the same UI, in any case. I realize when touch events are exposed we can interpret pinch-to-zoom as an actual map zoom, which is our desire.
It appears that this might be discussed upthread, so I'll try to catch up.For maps, I would expect Ctrl-+ to make all the text larger (including labels---I likely used Ctrl-+ because I have difficulty reading small type) but to be able to see more detailed coastlines (similar to how rounded corners are smoother).Seeing a more detailed coastline implies zooming the map in. If you blow up an existing view to make it larger (as will happen if you adjust the devicePixelRatio), you won't necessarily see more detail because we don't have it. To see more detail you need to actually zoom in the map, not the browser. Zoomed in pages will get blurry geometry if devicePixelRatio is adjusted.
Most folks today who pinch-to-zoom intend to zoom the map instead of the browser, which is part of our desire to know the browser zoom. It's likely a mistake. That will change once we have touch event support.
On Tue, Jul 9, 2013 at 3:26 PM, Michael Davidson <m...@google.com> wrote:
James, I'm still digesting your mail and will respond. You might be right, my objections might not be correct.
On Tue, Jul 9, 2013 at 2:45 PM, Adam Barth <aba...@chromium.org> wrote:Can you explain more of the "why" behind this statement? To be clear, we're talking about Ctrl-+/- (i.e., "full-page zoom") rather than the pinch-to-zoom feature of touch interfaces (i.e., page scale). Typically, when the user uses Ctrl-+, everything on the page occupies more physical space on their monitor, including buttons and labels. What does change, for example, are rounded corners, which have larger radii but smoother curves.Today pinch-to-zoom and Ctrl-+/- do the same thing, yes? They show the same UI, in any case. I realize when touch events are exposed we can interpret pinch-to-zoom as an actual map zoom, which is our desire.Sometimes! This world is complicated. Ctrl +/- increase/decrease the page zoom factor which is also controllable as 'Zoom' in the Chrome hot-dog menu. Most of the time - on Android and Windows 8 touch devices pinching influences a different scale factor called the page scale that is orthogonal to page zoom. On OS X (10.7+ iirc), pinching on some pointing devices (such as the trackpad on a macbook, some of their external mouse) is interpreted by chrome in a manner similar to Ctrl +/-. This is pretty inconsistent. Safari handles pinch gestures on OS X in a different way that's full of rounding errors and fail so let's not talk about that if we can help it. The OS X behavior for pinch on some devices is really an outlier in the Chrome universe and we might revisit it to mean something else.
On Tue, Jul 9, 2013 at 3:48 PM, James Robinson <jam...@google.com> wrote:
On Tue, Jul 9, 2013 at 3:26 PM, Michael Davidson <m...@google.com> wrote:
James, I'm still digesting your mail and will respond. You might be right, my objections might not be correct.
Seeing a more detailed coastline implies zooming the map in. If you blow up an existing view to make it larger (as will happen if you adjust the devicePixelRatio), you won't necessarily see more detail because we don't have it. To see more detail you need to actually zoom in the map, not the browser. Zoomed in pages will get blurry geometry if devicePixelRatio is adjusted.
Isn't that an application issue, though? If I have more physical pixels to display a certain amount of coastline, why wouldn't you load in whatever data is needed to render that coastline in a pretty way? The size of UI elements should be determined by CSS pixels and the number of physical pixels used to render that UI element should be determined by the devicePixelRatio. If for whatever reason (device scale, page zoom, whatever) I decide to map one CSS pixel to lots of physical pixels then I think the proper thing for maps to do is render both the UI elements and the vector content using lots of physical pixels. I don't think it matters *why* a CSS pixel maps to many physical pixels, the expected rendering is the same.
That said, I think that if you treat zooming the browser as adjusting the devicePixelRatio we will behave reasonably. You'll just get blurry tiles, which is probably OK.
B) If instead the user views the same scene on a high dpi device with devicePixelRatio of 2x, then you need to render the map differently. As before, you now need to represent San Francisco with four adjacent 128x128 tiles (or a single 256x256 tile) - i.e. you should have the same fine detail on coastlines etc as in A. But your labels need to remain as big as they were in the unzoomed case in order to remain legible; and since the physical area of screen on which you are drawing this hasn't increased, that means you'll probably have to draw less labels than in A (or at least space them out less); in fact you probably want to draw the labels the same way you were drawing them in the unzoomed case.
On Wed, Jul 10, 2013 at 10:01 AM, John Mellor <joh...@google.com> wrote:
B) If instead the user views the same scene on a high dpi device with devicePixelRatio of 2x, then you need to render the map differently. As before, you now need to represent San Francisco with four adjacent 128x128 tiles (or a single 256x256 tile) - i.e. you should have the same fine detail on coastlines etc as in A. But your labels need to remain as big as they were in the unzoomed case in order to remain legible; and since the physical area of screen on which you are drawing this hasn't increased, that means you'll probably have to draw less labels than in A (or at least space them out less); in fact you probably want to draw the labels the same way you were drawing them in the unzoomed case.The way this works today is that we use a single 256x256 tile, but things like label size and road width are specified in CSS pixels, so it looks essentially the same. The server stores geometry with ~.25px detail, so you do get some finer detail, but you won't if your devicePixelRatio gets above 4.
You get the same number of labels in the same position; SF still takes up 128x128 CSS pixels, we just have a bigger backing store.We've done the work to make this work.
Brandon is correct, though, that if you get much larger than 2 in the ratio your viewports can get too large for the browser to render. At this point we could start using CSS to scale.
As far as blurriness when you zoom in, we could definitely make this better if it's a common case, although this would be easier to do if we actually knew the browser zoom. Right now we get labels as pre-rendered glyphs from the server at twice the size they're going to display. This lets us rotate them and get reasonable quality, as well as render them reasonably sharp at high DPI. To keep labels sharp at much larger ratios we'd have to re-request tiles with bigger labels, which would be costly.
I'm not sure I'm following what's being proposed here. I worry at comments like 'so [they] don't need the tiles to be perfectly crisp' because I don't at all agree with the idea that people who want UI elements larger don't care if things are blurrier.
If I'm building an application that uses <canvas> to draw its UI I want to be able to get the same behavior DOM elements do with respect to page zoom. That is, I want a rounded rect drawn in my canvas to be just as crisp as a <div> with rounded borders when my page zoom is >100%. Am I just misreading that it's considered ok if that's not possible?
window.devicePixelRatio has always been a value that can change at runtime. For instance, a user may drag a tab from a high-DPI monitor to a lower one or may change their system settings. Correctly authored pages should deal with this today no matter what page zoom does. The browser will handle updating which media queries match, so the author only had to worry about assets they manage themselves.
- James