[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, Nov 4, 2010 at 2:05 AM, Gregg Tavares (wrk) <gman@google.com> wrote:
> On Wed, Nov 3, 2010 at 11:17 PM, Cedric Vivier <cedricv@neonux.com> wrote:
>> On Thu, Nov 4, 2010 at 10:11, Kenneth Russell <kbr@google.com> wrote:
>> > On Thu, Sep 30, 2010 at 2:58 PM, Steve Baker <steve@sjbaker.org> wrote:
>> > 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.
>> I'm not sure I like this approach, this is a bit too implicit imho.
>> Setting or manipulating any variables/arguments related to drawing
>> buffer dimensions (viewport, scissor, readPixels) would then need to
>> use the values returned by this new function to give correct behavior
>> in all cases.
>> However it is highly unlikely imho that most developers would use it
>> this new function everywhere it would be need for consistent behavior
>> in case of downsizing. Indeed, canvas.width and canvas.height are the
>> most intuitive/easiest/straightforward/canvas2d-like way to do it and
>> not using this new function would never show any issue except in the
>> rare(?) cases when the WebGL implementation has to downsize the
>> backing store.
>> IMHO backing store resizing should be an implementation detail that
>> the developer does not have to think about, I propose another option :
>> 4) At context creation, the WebGL implementation might setup a drawing
>> buffer with different dimensions than the canvas, *provided that the
>> dimensions have the same aspect ratio than the canvas*.
>> Internally, the scale ratio (1.0 by default) is used to "correct"
>> width/height input arguments given to viewport, scissor, and
>> readPixels.
> If I have a 9 monitor setup and I stretch the window across all 9 1280x1024
> monitors and my max back buffer is 2048 then I get a 2048x128 backbuffer?
> That doesn't seem like the result I want. Most of the time I want the
> largest resolution I can get.
> If your app needs a 1.0 scale ratio then query the max backbuffer size and
> then set the size of the canvas appropriately. Only about 4 of the last 60
> 3d apps I've written would have needed this. Most of my apps in WebGL pick a
> fixed backbuffer size and let the canvas scale automatically.
> It seems like it's better to do the best thing for the majority of apps.
> Those few apps that need a 1.0 scale ratio can do what they need to force
> it.

I agree. The majority of the 3D applications and demos I've written
handled resizing the window to arbitrary sizes, and adjusted the
projection matrix as necessary.

Requiring that the aspect ratio of the canvas's width and height be
preserved goes against the OpenGL philosophy that the APIs have as
little mechanism behind them as possible. We've adhered to this
philosophy in other areas such as not automatically adjusting the
viewport when the canvas is resized.

>> We might provide a "float getDrawingBufferScale()" API to expose that
>> information, could be useful to load lower resolution textures for
>> instance, however  this is not necessary for correct and consistent
>> behavior whether or not the buffer has been scaled... in fact we
>> probably should not expose this information at all.

It is absolutely necessary for certain applications to understand the
precise dimensions of the back buffer, for example so they can make
correct glViewport calls.


>> Regards,

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: