[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 (çç) <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.
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).
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 (çç) <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),