From: Vladimir Vukicevic <email@example.com
Date: Wed, 22 Sep 2010 00:43:56
To: Gregg Tavares (wrk)<firstname.lastname@example.org
Cc: Chris Marrin<email@example.com
>; Kenneth Russell<firstname.lastname@example.org
>; public webgl<email@example.com
>; Steve Baker<firstname.lastname@example.org
Subject: Re: [Public WebGL] Behavior of WebGL canvas when it can't make a
backbuffer of the requested size?
----- Original Message -----
> so yea, I think the canvas should just pick the largest size it can up
> to the size you ask for. You then check canvas.width and canvas.height
> to see what size you actually got.
> If you don't check it's no worse than now where most likely something
> bad would happen. If you forget to check and someone reports a bug in
> your app it will be super easy to fix your app.
Interesting. I agree with this idea, but we should get this into the canvas spec as well then -- the notion that a context might set lower width/height than what was requested, but scale it up for final display. Or would it scale it up? Or just use a smaller than requested canvas? If we add the the scale piece, then we'd just need to add something like actualWidth/actualHeight (or perhaps pixelWidth/pixelHeight). At one point there was a desire to have canvas be resolution agnostic, so that, for example, the browser would be allowed to create a 2x resolution canvas for a high dpi display, managing the extra scale factor under the hood. WebGL could just as easily create an 0.5x resolution canvas, as long as we allow the author a way to query the actual pixel dimensions. I think that's better than just modifying the actual size of the canvas, because that's likely to mess up the page's layout as well.
At the same time, we really, really should add a setSize() call on canvas that allows setting width and height at the same time. The current way is pretty silly if you're doing frequent resizes.