On Mon, Jun 18, 2012 at 5:58 PM, Glenn Maynard <firstname.lastname@example.org>
On Sat, Jun 16, 2012 at 1:34 PM, Gregg Tavares (çç) <email@example.com>
I must be missing something. That attribute would break many samples.
The entire point is that existing code doesn't request this, so *nothing* would break.Â
The goal of allowHighRes it to magically make apps high res but as we've pointed out that's impossible given the way OpenGL works. Is there some reason these issues keep getting ignored?
No, the goal is to give the browser control over the drawing buffer ratio, and to give application developers a chance to update their applications so this doesn't break existing code.
How is the browser supposed to know the desired physical backing store size?
On Mon, Jun 18, 2012 at 3:30 PM, Kenneth Russell <firstname.lastname@example.org>
A WebGL application desiring higher resolution on a high-DPI display
can scale canvas.width and canvas.height by window.devicePixelRatio
The .width and .height attributes on HTMLCanvasElement are
in CSS pixels by definition.Â All this is doing is creating more testing scenarios, violating the HTML spec, and making the use of HTMLCanvasElement confusingly different across context types.Â (If you set up a 2d context this way, you'd end up with a 4:1 pixel ratio backing store on a 2:1 device.)
The width and height attributes are just numbers, the way that various CanvasContext types use the attributes is up to those contexts. ÂCanvas 2d can do one thing with them and WebGL can do another, if that's desired (I'm personally decidedly unconvinced that what Apple has done with canvas 2d is really a good idea).
(or whatever the standardized solution ends up being),
That only works for 2d contexts, it doesn't work for WebGL.