On Fri, Jun 15, 2012 at 12:01 AM, Mark Callow <email@example.com>
On 15/06/2012 15:21, Gregg Tavares (çç)
I'm not sure what your point is. Yes, the code could be
written better to deal with exceptional cases but it will
rarely hit those cases. Are you suggesting a change in the
spec that would make code magically work?
My point is solely that the code is broken. I thought you were
trying to change the spec. to make such code magically work.
No, I wasn't. Sorry if I didn't make that clear.
The intent of the spec as written is
1) Give the developer
exactly what they ask for. If they ask for 640x480 they
I don't remember us ever discussing changing canvas width and height
from css pixels and we certainly didn't do it. Therefore the
developer has never been able to ask for a 640 x 480 device pixel
canvas. I am only pointing this out. I do not think we should change
the meaning of canvas width and height.
I think we both agree. ÂThe point I'm trying to make is that canvas.width and canvas.height specify 2 sizes
1) the size the canvas will be displayed IF the user didn't specify a display size using CSS style
2) the size of the backing store (drawingBuffer) that will be used when rendering the canvas.
for 2d contexts, the browser can choose a different size. This is apparently the norm on HD-DPI displays
for WebGL contexts the browser must not choose a different size. Otherwise WebGL programs will breakÂ
So, specifically, I believe we need to update the WebGL spec to make it explicit that for WebGL contexts, they always get aÂdrawingBufferÂthe size requested. Unlike 2d contexts, the browser is not allowed to make it a different size on HD-DPI displays.
(excepting the MAX_VIEWPORT_DIMS limits which are already part of the spec)