[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] How to unambiguously set canvas pixel size to be pixel-perfect?
This issue is a deep one which can't be solved in isolation in the
WebGL spec. Even ignoring page zoom, adding a context creation
attribute like "scaled: false" will break many invariants in the web
platform. For example, it would cause changes to the CSS width and
height properties to have the side-effect of resizing the WebGL
canvas's backing store. Resizes would start coming in asynchronously
to the WebGL app. I don't think any browser implements per-element
resize events. There would likely be other surprising and undesirable
It's possible that https://www.khronos.org/webgl/wiki/HandlingHighDPI
just needs to be updated. If there are better ways to measure the
number of device pixels that a given region or canvas will cover then
let's update the page. Boris Zbarsky pointed out the
getBoundingClientRect, getClientRects, and getBoxQuads APIs. Could
someone who's been investigating this in depth please try them and see
whether they solve the problem? I suggest considering the unzoomed
case first because it seems to be the most common case.
On Wed, Jun 11, 2014 at 12:05 AM, Evan Wallace <firstname.lastname@example.org> wrote:
> This is an issue I'm struggling with too. There aren't any problems with
> framebuffer size in my case though. I'm trying to cover most of the screen
> with a WebGL canvas and that area has the same number of physical pixels
> regardless of zoom level (well, it's really a little less after you zoom in
> because the UI around the canvas grows in size a bit).
> DPI handling works by setting the canvas width/height to the CSS
> width/height times the devicePixelRatio, so the canvas framebuffer is
> approximately scaled 1:1 with physical pixels. For fullscreen WebGL apps,
> zooming in makes the window size go down and the devicePixelRatio go up to
> The problem is that CSS only lets you set the canvas size to integer values,
> and most of the time it's impossible to specify an integer width/height such
> that the zoomed canvas is exactly the size you need. Demo showing the
> problem: http://fiddle.jshell.net/V884T/show/ (zoom in and the grid won't
> match 1:1).
> Strawman API proposal: add a "scaled: false" parameter to the WebGL context
> creation attributes that would always render the framebuffer from the top
> left corner at 1:1 with physical pixels (i.e. not scaled) without affecting
> the size of the canvas element itself.
> On Tuesday, June 10, 2014, Rik Cabanier <email@example.com> wrote:
>> On Tue, Jun 10, 2014 at 10:41 PM, Tony Parisi <firstname.lastname@example.org> wrote:
>>> I am skeptical of that figure... Where is the data to support it?
>>> My guess is that less than 5% of users even know about the zoom
>> I was very surprised about that figure too. It's been over a year since he
>> sent that out and I'm having trouble finding his message.
>>> And yeah it's bad for WebGL graphics
>>> Tony Parisi
>>> CTO at Large
>>> On Jun 10, 2014, at 10:31 PM, Florian Bösch <email@example.com> wrote:
>>> On Wed, Jun 11, 2014 at 7:25 AM, Rik Cabanier <firstname.lastname@example.org> wrote:
>>>> Browser zoom (= ctrl/cmd +/-) also affects DPR.
>>>> Someone from Google maps stated that 15% of all users have some level of
>>>> browser zoom enabled.
>>> I didn't know that. That's quite odd, and completely unusable for WebGL
>>> because there are limits to the size you can set a framebuffer to as well as
>>> that rendering to ridiculous resolutions would become very slow, very
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: