On Sat, Jun 16, 2012 at 1:24 PM, Florian Bösch <firstname.lastname@example.org>
On Sat, Jun 16, 2012 at 10:12 PM, Gregg Tavares (社用) <email@example.com>
What? I think we are talking past each other. "allowHighRes" = "automatic backing store size selection by the browser according to resolution conversion from CSS pixels to backing store size" which is another way of saying "allowHighRes" = "broken programs"
"allow" is an "opt-in" kind of thing. Nothing will automatically break because you introduce an opt-in mechanism.
It will break because you have to test. That's what I mean by automatic. Lots of programmers will add "allowHighRes" either by using a library, by copying boilerplate code or just by not understanding the implications. They won't personally have an HD-DPI machine so their app will work. They'll have no idea of all the rules they broke. Hence, it will break automatically when put on an HD-DPI machine.
On any account, you currently have no reliable way to query the native resolution, so even if you wanted to do the "allow" thing yourself by converting width/height transforms and setting corresponding canvas.width/height, you can't.
You already know the backbuffer resolution. It's the same values you put on the canvas. All I'm suggesting is that specific requirement needs to get added to the WebGL spec. If you'd like to know what resolution that will be scaled to when displayed you multiple them by window.devicePixelRatio
You will either have to create a reliable API that helps you query the correct factor by which to multiply your canvas.width/height setting, or you will have to introduce some attribute ala "allow this or that", I really don't fundamentally care, because it doesn't really matter if your conversion calculation flows to the canvas, or you derive your conversion calculation from the canvas. It's funcationally equivalent and you're just arguing about semantics.