On Thu, Jun 14, 2012 at 8:35 PM, Gregg Tavares (çç) <firstname.lastname@example.org>
If the user sets the width to 800x600 they'll get an 800x600 canvas and an 800x600 backbuffer. If they want it HD-DPI they can set the css width to 400px by 300px. That's the same as it is today.
It means you have to change the width and height in script, which will cause the intrinsic dimensions of the canvas to change.Â That means you'll have to jump further hoops: check to see if a width/height style is already set, and if not, copy the @width/@height to it--so the size of the rendered canvas doesn't change--before multiplying canvas.width/height by the ratio.Â This is all stuff the browser is supposed to take care of, by HTMLCanvasElement's design.
It means every app needs boilerplate along these lines:
ÂÂÂ var cs = document.defaultView.getComputedStyle(canvas);
ÂÂÂ if(cs.width != "") cs.width = canvas.style.width + "px";
ÂÂÂ if(cs.height != "") cs.height = canvas.style.height + "px";
ÂÂÂ cs.width *= window.devicePixelRatio;
ÂÂÂ cs.height *= window.devicePixelRatio;
ÂÂÂ var gl = canvas.getContext("webgl");
All the allowHighRes option means is that the browser takes care of all that (as Canvas's design intends).Â It also avoids the side-effects on the canvas element, which is useful; you don't need to carefully revert it if WebGL context creation fails and you want to attempt another context type, and it avoids making the intrinsic dimensions of the canvas wrong (which is what necessitates the style override).Â I don't see the problem with this.