[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] How to set a canvas backing store to display units?

On Sat, Jun 16, 2012 at 1:34 PM, Gregg Tavares (çç) <gman@google.com> wrote:
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.
On top of that there's no reason to implement allowHighRes in the browser when a simple _javascript_ wrapper on top of the current API can provide most if not all of that same functionality if you want it.

Both Ian and I have explained problems with doing this with _javascript_ and CSS.

On Sat, Jun 16, 2012 at 3:12 PM, Gregg Tavares (çç) <gman@google.com> wrote:
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).

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).

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 (çç) <gman@google.com> wrote:
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 <kbr@google.com> wrote:
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),

We already have a standardized solution: .width and .height are in CSS pixels, and the context picks an appropriate backing store size. http://www.whatwg.org/specs/web-apps/current-work/#canvas

Glenn Maynard