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

  -- 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: