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

Re: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size?

On Thu, Sep 30, 2010 at 2:58 PM, Steve Baker <steve@sjbaker.org> wrote:
> Gregg Tavares (wrk) wrote:
>> On Wed, Sep 29, 2010 at 5:50 PM, Chris Marrin <cmarrin@apple.com
>> <mailto:cmarrin@apple.com>> wrote:
>>     On Sep 29, 2010, at 2:37 PM, Gregg Tavares (wrk) wrote:
>>     >
>>     >
>>     > ...And I assume that when that's done an implicit transform is
>>     applied to make it look to the user like the canvas is the
>>     requested size? That's what I suggested in the first place, but it
>>     was pointed out that hiding the actual size from the author like
>>     that is not really possible. Canvas 2D doesn't have concepts like
>>     viewport, which are not affected by transforms. And WebGL doesn't
>>     have an overarching transform that is applied to everything. I
>>     don't see how you can have a drawing buffer that is not the
>>     requested size without the rendering coming out all wrong. If so,
>>     you're not helping the author by doing things behind his back.
>>     >
>>     > For 99% of WebGL apps they should be using canvas.clientWidth
>>     and canvas.clientHeight as the dimensions for computing rendering
>>     aspect. Those will always be correct regardless of the backbuffer
>>     size.
>>     I don't understand what you mean. clientHeight and clientWidth are
>>     the size in pixels of the canvas image on the page, which has
>>     nothing to do with the size of the drawing buffer. I believe there
>>     will be many uses for WebGL where the drawing buffer size is
>>     different from the client size for performance, etc.
>> Most WebGL apps call a function modeled after gluPerspective
>> <http://www.opengl.org/sdk/docs/man/xhtml/gluPerspective.xml> to
>> compute a perspective projection matrix and set the aspect ratio such
>> that their images show up with the correct aspect. The correct aspect
>> ratio to pass in is canvas.clientWidth / canvas.clientHeight.  It is
>> NOT canvas.width / canvas.height. The aspect ratio that needs to be
>> passed in is the size at which the result will be displayed, not the
>> size it's rendered. The size that it's rendered is rarely relevant to
>> anything in a WebGL app except for rendering quality.
> There are some very specific algorithms (like screen-space ambient
> occlusion, for example) that really require you to know the true screen
> resolution.  I don't think it matters that you don't get the resolution
> you asked for so long as you can always find out what the resolution you
> have is.
> Traditional fixed-function pipeline OpenGL applications do indeed use a
> projection matrix - which you could possibly intercept and modify if
> that helped - but with the advent of vertex shaders, all bets are off
> and applications can send whatever matrices they like however they like
> - so there is no longer a single place to change that.  But the viewport
> and scissor commands are the ones you'd need to be careful with.
> I'd still prefer a system where we explicitly say that the context
> dimensions you ask for are merely suggestions from the application (just
> like the stencil and depth buffer precisions) - which the browser may
> choose to ignore, making the actual resolution either larger or smaller
> - and hence, applications should ALWAYS query the system to find out
> what resolution they actually have.

Apologies for the delay getting back to this, but the WebGL working
group strongly wants to resolve this issue. As I understand it the
viable options when setting the canvas's width or height to a value
unsupportable by the underlying OpenGL implementation appear to be:

1. Make the largest supported backing store, and stretch it to fit the
canvas's area on the web page. Add an API to WebGLRenderingContext,
"long[] getDrawingBufferSize()", returning the actual width and height
of the backing store.

2. Set a synchronous error condition on the canvas which can be
checked via a new API such as "boolean isDrawingBufferValid()". Draw
calls either raise an error or are ignored.

3. Raise a WebGL context lost event when the canvas is resized too
large, and a context restored event when it is shrunk back to a
supported size.

At this point I continue to believe that (1) is the best option for
web developers. Naive developers will get mostly correct results,
which based on discussion with Tab Atkins are better than no results.
I would no longer advocate (3) as it is too complex to handle. Raising
an exception from the setting of canvas.width or canvas.height does
not seem to be a viable option as it changes the semantics of these

I propose that we update the spec to indicate that WebGL
implementations do (1). Please send any comments to the list.


You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: