[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 Nov 5, 2010, at 11:33 AM, Kenneth Russell wrote:

...The last question is whether or not there is a call that will tell the author the maximum dimensions of the drawing buffer. There is MAX_VIEWPORT_DIMS which will probably give the right answer. But I don't think there is any guarantee that the window system maximums are reflected in MAX_VIEWPORT_DIMS. So we should either clarify that this value will always give the right answer or create a new call to give the max dimensions.

I don't think this is feasible. In certain low memory situations I
could imagine that a WebGL implementation might not be able to
allocate a backing store texture of the maximum dimensions, or in fact
even know what the largest allocatable texture is at the moment
without actually trying the allocation since OpenGL ES doesn't have
proxy textures.

Instead I think the spec should simply state that the dimensions of
the back buffer may be clamped to implementation dependent maximums.
The getDrawingBufferSize() API may be used to query the allocated size
of the drawing buffer.

Ok, so an author who wants to have fine control over the drawing buffer size would have to request the desired size and then see that a smaller drawing buffer was allocated. If that size is not good enough, the author can make another attempt at sizing the buffer, hopefully using the returned size as a metric. This could happen over and over as the author tries to find a reasonable buffer size. And the heuristics used might work well on one platform and not on another.

I suppose the above scenario is not too bad. But it would be very nice if we could give the author some clue about the buffer size constraints.