[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] How to set a canvas backing store to display units?



If an attribute were added I'd prefer it to be a pixel scaling ratio ala 'backingPixelRatio' - that way one could pass window.devicePixelRatio to always get a native 1:1 backing store, or if they wanted to render at a lower resolution (performance/quality tradeoff) they easily could by supplying a different value. Just as with all context attributes the implementation could ignore it or change it and it's up to the application to query and see what they got (aka still don't use canvas.width/height).

Because most people's apps are broken w.r.t. backing dimension differences, I'd say that the spec should be updated to say that if an application doesn't pass in a value for 'backingPixelRatio' (or whatever) indicating that they know what they are doing and a backing store could not be allocated due to MAX_TEXTURE_SIZE issues, the GL context creation should just fail. Users would get (assuming app authors were thorough) a better failure message than just garbage rendering that would occur otherwise.

On Fri, Jun 15, 2012 at 2:51 PM, Florian Bösch <pyalot@gmail.com> wrote:
On Fri, Jun 15, 2012 at 11:38 PM, James Robinson <jamesr@google.com> wrote:
Canvas 2d is (mostly) a vector API, so you can write canvas 2d code that does not care how many pixels are in the backing store and it will Just Work.

That is definitely not true for OpenGL or WebGL - in general it is not possible to write code that works correctly that does not care about how many pixels are actually in the backing store.  I think this is the fundamental difference between 2d canvas and WebGL and not something we can gloss over with an option or attribute.
I think what Glenn tries to make sure with that attribute is to avoid 99% of webgl samples breaking on high dpi devices because they're not using drawingBufferWidth/Height, but make it possible to "opt-in" to high-dpi devices true resolution, right? So that attribute wouldn't "gloss over" the difference, but retain the semantic that most people have coded against so far, while letting them gradually ease into doing things right.