[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 Wed, Sep 29, 2010 at 5:50 PM, Chris Marrin <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 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. 
 

-----
~Chris
cmarrin@apple.com