[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?

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.

  -- Steve

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: