[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 10:00 PM, Steve Baker <steve@sjbaker.org> wrote:
>> On 11/03/2010 09:11 PM, Kenneth Russell 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.
>>> 2. Set a synchronous error condition on the canvas which can be
>>> checked via a new API such as "boolean isDrawingBufferValid()". Draw
>>> calls either raise an error or are ignored.
>>> 3. Raise a WebGL context lost event when the canvas is resized too
>>> large, and a context restored event when it is shrunk back to a
>>> supported size.
>>> At this point I continue to believe that (1) is the best option for
>>> web developers. Naive developers will get mostly correct results,
>>> which based on discussion with Tab Atkins are better than no results.
>>> I would no longer advocate (3) as it is too complex to handle. Raising
>>> an exception from the setting of canvas.width or canvas.height does
>>> not seem to be a viable option as it changes the semantics of these
>>> attributes.
>>> I propose that we update the spec to indicate that WebGL
>>> implementations do (1). Please send any comments to the list.
>> Excellent!   I agree.
>> This way, you are rendering to a smaller surface than you asked for (and
>> you can query the dimensions that you actually got) - and the resulting
>> image will be stretched as necessary (presumably by the compositing
>> software) to make it cover the area you actually asked for.  But please,
>> let's not try to automatically compensate with viewport dimensions and
>> such.  It should be up to the application to get that right by using the
>> numbers returned by getDrawingBufferSize()
>> Also, can the specification provide a guarantee that the aspect ratio of
>> the reduced surface will be (to within reasonable hardware limits) the
>> same as the application asked for?  Some algorithms behave badly with
>> non-square pixels.
>> eg: If I asked for 512k pixels as a 1024x512 rendering buffer - but
>> there were only 320k pixels of storage available - then I should
>> reasonably expect to get back an 800x400 buffer rather than a 640x512 or
>> a 1024x320.
> How would you define "reasonable hardware limits"? Having one
> dimension be off by no more than one or two pixels from the ideal,
> potentially fractional, value when preserving the aspect ratio? Off by
> no more than a certain percentage? What about pathological cases of
> very wide or very tall canvases?

Well, I thought about saying "accurate to the nearest pixel" - but then I
wondered whether some hardware might have trouble with (say) windows that
are not a multiple of 4 pixels wide.  But what I want is "accurate to the
nearest pixel" - and I'd be happy to have the spec say that.

> I think we should keep it simple. No guarantees about preservation of
> aspect ratio. If the app wants to do the right thing, the app should
> query both getDrawingBufferSize and canvas.clientWidth/clientHeight
> depending on the values needed.

But then, we leave ourselves open to bad drivers that when asked for a
1024x512 return you a 1024x32 and stretch it to fill the canvas.  Since we
can't tolerate that case, all applications are forced to repeatedly try to
create canvases of god-knows-what random sizes in an effort to get back
something they can live with that won't stretch or squash their data to an
unbearable degree.

The specification absolutely has to specify some sort of rule as to what
the system will do when there isn't enough memory - and since it's going
to rescale the render buffer to fit the canvas, preserving the aspect
ratio is the rational choice.

  -- Steve

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: