On Sun, Jun 17, 2012 at 10:08 PM, Ben Vanik <firstname.lastname@example.org>
(I think you meant to respond to the list)
This is yet another place where tools can help - no need for a real machine. I'd like to see some simple behavior fuzzing features in web inspectors, for example, that change backing store sizes, lose/restore the context, fail randomly, set capabilities/extensions to standard config levels, etc.
You shouldn't need tools. That's not a good API where you only know if you got it right by testing in various configurations and tools.
If you write
gl.uniform2f(resolutionLocation, canvas.width, canvas.height)
And it works for you it should work everywhere. If the browser magically chooses a different resolution it won't work everywhere.
On Sunday, June 17, 2012, Gregg Tavares (社用) wrote:
Designing an API which you only know if you're using it correctly by having to buy and test on multiple machines is not good API design.
Any version of WebGL in which the browser magically decides on the backbuffer resolution is a BAD api for precisely that reason because if you use canvas.width, canvas.height you'll have no idea that your app is broken.
On Sun, Jun 17, 2012 at 7:30 PM, Ben Vanik <email@example.com>
Agreed. Not ensuring good behavior now when the spec is still so young is just going to end leading to slide decks full of 'the things we did wrong 10 years ago when we specced WebGL'. A few broken demo pages today is a small price to pay for the success of all future apps.
Q: is everyone still behind experimental-webgl? If so, revise the spec going forward and for conformance make it so browsers aren't allowed to ship 'webgl' without the proper scaling. Old apps that are using canvas.width/height will use 'experimental-webgl' and can continue to work, new apps using 'webgl' will get the desirable automatic scaling behavior. If current apps are doing a search through ['webgl', 'experimental-webgl'] (which they *should not be*), they're broken anyway.
On Sun, Jun 17, 2012 at 7:05 PM, Mark Callow <firstname.lastname@example.org>
On 17/06/2012 05:30, Gregg Tavares (社用)
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
To be setting up a world where WebGL applications render to small
drawing buffers and get zoomed up is so so so wrong. GL is all about
transforms. App's should be written to draw at any size. It's not