[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 Mon, Sep 27, 2010 at 10:02 AM, Chris Marrin <email@example.com> wrote:
> On Sep 24, 2010, at 4:50 PM, Steve Baker wrote:
>> IMHO, there needs to be a distinction between opening an overly-large
>> web context - and resizing one after creation.
>> In the former case, it would be nice if WebGL could do the best it can
>> to meet your demands - just as it does if you demand (say) antialiassing
>> and it can't do it. Of course we must provide some means (such as
>> querying the canvas.height/width) to find out that you didn't get what
>> you wanted. This allows simple applications to be as uncomplicated as
>> possible and that's important for widespread adoption.
> But the simple app would not be uncomplicated. If we set the size to something other than the requested canvas width and height we would have to do some sort of scaling, which would mess up the viewport, etc. And we can't set the width and height out from under the author. Even if we did, a simple app might not look at that and do the wrong thing anyway.
> I think we need to fail to create the drawing buffer, but not fail to create the context, and let the author deal with it from there.
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:
returning an array of length 2 containing the width and height in
pixels of the drawing buffer.
WebGL authors should just use this API all the time instead of
querying the canvas's width and height.
>> In the latter case - which is a more sophisticated operation, producing
>> an error message and either refusing to do the resize or producing the
>> largest allowed size would seem to be the simplest thing...again, with a
>> way to query what you have left after all the fuss has died down.
>> I'd like to avoid loss-of-context stuff at all costs.
> I don't think there is ever a need to have a context lost. In the case of using an FBO for the drawing buffer, the operation is definitely not destructive to the context. Even using a window manager, it's possible to resize the window without affecting the context, at least on all the platforms (WGL, CGL, GLX) I've used.
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: