On Mon, Jun 18, 2012 at 5:58 PM, Glenn Maynard <email@example.com>
On Sat, Jun 16, 2012 at 1:34 PM, Gregg Tavares (社用) <firstname.lastname@example.org>
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.
As I've keep saying. This is the WRONG thing to do. In canvas 2d changing the drawing buffer ration effects nothing from the pov of the developer. No matter how you write your code it just works. That's not true for WebGL.
Case 1) WebGL backbuffers are allocated 1x1 pixels for CSS pixels (as they are today)
Nothing breaks ever. You ask for a certain size you get it. No testing on multiple platforms required.
Case 2) WebGL backbuffer resolution is decided by the browser (opt-in or not)
You write some code, you have no idea if it works when the browser chooses another resolution on a machine you don't own. That's unacceptable
On Sat, Jun 16, 2012 at 3:12 PM, Gregg Tavares (社用) <email@example.com>
I'm advocating that browsers should NOT choose the
backing store resolution automatically. They should be required to make
it 1x1 with CSS pixels for WebGL contexts. No programs will break in
this case and the option to make them HD-DPI already exists by setting
the canvas size higher and using CSS style to set the size it's
displayed on the page. This part is already how it works today.
You seem to be saying that making people set "canvas.width = cssPixels * ratio" would eliminate the need to test on HD devices, but it wouldn't. It'd just trade one set of bugs for another. You still need to test, to make sure that your CSS style adjustment (which you have to do to compensate for messing with the canvas dimensions) is having the correct effect when it causes canvas.width != canvas.style.width, and that it doesn't have any unexpected side-effects (stomping on another CSS style, not being reverted when needed, and so on).
Setting it explicitly puts the responsibility in the developers hands. If they don't change it nothing breaks. If they do change it it's the same as it is today. Several apps already set their own resolutions. http://glsl.heroku.com
has a resolution setting at the top. Set it 2 you get 1/2 res backbuffers, set it to 1 you get a 1x1 res backbuffer, set it to 0.5 you get a double res backbuffer (which would display 1 to 1 on an HD-DPI display)
There's no need for an automatic setting by the browser that the developer might set, not knowing the repercussions and then having there app break on other machines.
On the other hand, it doesn't even eliminate the need to test the case where drawingBufferWidth differs from what you requested, due to the texture limitation case. It's increasing testing requirements, not reducing them--now you have to test both on HD devices (where canvas.width == gl.drawingBufferWidth, but the size is overridden by CSS) *and* the texture limitation case (where canvas.width > gl.drawingBufferWidth).
As I keep saying, that issue is basically a non-issue. It's only there to prevent crashes, 99.99% of developers can safely ignore it. No one has run into it even though thousands of webgl apps are in the wild so please stop using this as an excuse. That suggested attribute on the other hand would require every developer to be acutely aware of the issues.
allowHighRes avoids that: high-res backing stores are just another instance where the two differ, which they can anyway. It doesn't add a whole new axis that needs testing. A nice side-effect of this is that both cases help the other: people fixing their code for HD backing stores will, as a side-effect, fix their code for texture limitations, and vice versa.
On Sat, Jun 16, 2012 at 3:58 PM, Gregg Tavares (社用) <firstname.lastname@example.org>
What I'm suggesting is
canvas.size == backing store size
Period. Always. No Options.
Texture size limitations. Remember?
On Mon, Jun 18, 2012 at 3:30 PM, Kenneth Russell <email@example.com>
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.)
(or whatever the standardized solution ends up being),
Yes, the 2d context will choose what's appropriate for it
The WebGL contezt will choose differently what's appropriate for it.
You can't force resolutions on a context. You could just as easily have
or some other future context for it would be impossible to choose a backbuffer resolution