[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 <email@example.com
> <mailto:firstname.lastname@example.org>> 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
> 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
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.
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: