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

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.

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: