[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 Mon, Jun 18, 2012 at 5:58 PM, Glenn Maynard <glenn@zewt.org> wrote:
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.

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

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 (çç) <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

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

 ÂgetContext("video");
 ÂgetContext("webrtc");

or some other future context for it would be impossible to choose a backbuffer resolution

Â


--
Glenn Maynard