[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 Sep 28, 2010, at 12:27 PM, Vladimir Vukicevic wrote:

> 
> 
> ----- Original Message -----
>> After more thought, using a context error event is going to make life
>> hard for application developers. Their resizing logic will be
>> straight-line, but errors during setup requiring resizing to a smaller
>> size will be reported asynchronously.
>> 
>> Tab Atkins (who works on the Canvas spec) and I discussed this, and it
>> sounds like the solution that's most compatible with the current style
>> of web development is to silently handle this situation: make the
>> WebGL back buffer as big as possible, scale it to the canvas's width
>> and height, and provide an API to find out the real backing store
>> size. This is similar to the behavior of CanvasRenderingContext2D in
>> several ways: the fact that the backing store size doesn't need to
>> match the canvas's size, and the fact that CSS styling can stretch the
>> canvas. Throwing an exception during canvas resizing is undesirable
>> since the entire web site is likely to stop working, where it could
>> "mostly work" otherwise.
>> 
>> I propose that we add the following API to WebGLRenderingContext:
>> 
>> long[] getDrawingBufferSize();
> 
> Yep, this makes sense to me -- but I'd suggest that we just add a new glGet query instead of a new API call. Something like DRAWING_BUFFER_SIZE_WEBGL; the author already has to query DEPTH_BITS/STENCIL_BITS/etc. to figure out whether their ContextParameters were honored and how, so this seems like a pretty natural extension.

GL is the wrong place for this query. Drawing Buffer size has nothing to do with GL, but with the system interface library. And it would be a departure to have the actual size of the drawing buffer not match the requested canvas width and height. If this situation arises, I would rather have the author be unable to draw rather than having it draw incorrectly. In fact, to make the author's life easier, I think we should return errors from the drawing calls. That way when they looking for the cause of lack of drawing they will see NO_DRAWING_BUFFER errors which tells them the problem.

-----
~Chris
cmarrin@apple.com




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