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

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.


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.