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

Re: [Public WebGL] HI-DPI displays and WebGL issues

(Why did you start two threads?)

On Tue, Jun 12, 2012 at 8:14 PM, Gregg Tavares (社用) <gman@google.com> wrote:
2) require WebGL to translate from css units to device units when calling gl.viewport and gl.scissor if there's no fbo bound.

would that work? It sounds like it could be confusing.

This is definitely how Canvas is intended to work.

Remember that users can zoom in and out of the page at any time in mobile browsers (and to a lesser extent on desktop browsers).  This changes the scaling factor between CSS pixels and hardware pixels in realtime.  All this should do, in practice, is cause the backing store to be scaled transparently to the new size during compositing, without the user's code having to set a new viewport.  From the perspective of a WebGL app, nothing changes at all and the canvas remains at the same size, since this zooming doesn't change the CSS size of the canvas.

As far as the API is concerned, the "device" should *be* the canvas in CSS "space".  Any scaling happening after that is just a compositing detail.

On Tue, Jun 12, 2012 at 9:25 PM, Cedric Vivier <cvivier@mozilla.com> wrote:
Afaik we currently explicitly allow a WebGL implementation to use any
backing store size as it sees fit (cf. 5.14.1).

I believe this problem is already "solved" in the spec, since a
developer should use context.drawingBufferWidth/drawingBufferHeight
rather than the canvas's width/height to manipulate viewport/scissor
and such on the default framebuffer, isn't it?

I'm pretty sure you need to use canvas.width/height as arguments to viewport/scissor and never drawingBuffer*.  The WebGL implementation might decide to use a larger or a smaller backing store, but gl.viewport takes *window* coordinates.  If you request a 1000x1000 canvas and the backing store you get is 10x10, you still call gl.viewport(0, 0, 1000, 1000). 

(More importantly, it's what everybody is doing: it's what the example in the 2.3 says, it's definitely what I've always done, and googling for the canvas.width version gives about 10000 hits compared to 2 for the drawingBuffer one.  This is far too widespread to evangelize away.)

On Wed, Jun 13, 2012 at 12:41 AM, Gregg Tavares (社用) <gman@google.com> wrote:
I think there's a good argument to be made that WebGL canvas never have it's backing store size auto-adjusted by the browser.

If the hardware's max texture size is smaller than the size of the canvas, then it'll have no choice but to reduce the size of the backing store.

If browsers have to be allowed to make the backing store smaller, then there's no further harm introduced by allowing browsers to make it bigger, too.

the contents of backbufferPixels should equal the contents of fboPixels but if the browser is magically making the backbuffer a different size then you're gonna have a bad time

You'll need to fix the texture you're rendering into to use gl.drawingBuffer* instead of the canvas size, but if you don't do that you should usually just get a lower-resolution texture, not completely broken rendering.  It's a reasonable failure mode.

I've already explained a promising way to deal with readPixels.

Glenn Maynard