[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, Sep 29, 2010 at 2:00 PM, Chris Marrin <firstname.lastname@example.org> wrote:
> On Sep 29, 2010, at 1:35 PM, Kenneth Russell wrote:
>> On Tue, Sep 28, 2010 at 1:30 PM, Chris Marrin <email@example.com> wrote:
>>> On Sep 28, 2010, at 11:45 AM, Kenneth Russell wrote:
>>>> On Mon, Sep 27, 2010 at 10:02 AM, Chris Marrin <firstname.lastname@example.org> 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.
>>> The difference is that, with 2D Canvas, the size of the drawing area is always the specified canvas width and height.
>> From talking with Tab Atkins this is not guaranteed. It is legal for a
>> 2D canvas implementation to be higher DPI -- the number of pixels
>> across is not necessarily the canvas's width. Again, the only
>> situation where an author would discover this is when calling
> And I assume that when that's done an implicit transform is applied to make it look to the user like the canvas is the requested size? That's what I suggested in the first place, but it was pointed out that hiding the actual size from the author like that is not really possible. Canvas 2D doesn't have concepts like viewport, which are not affected by transforms. And WebGL doesn't have an overarching transform that is applied to everything. I don't see how you can have a drawing buffer that is not the requested size without the rendering coming out all wrong. If so, you're not helping the author by doing things behind his back.
As long as the WebGL author uses
WebGLRenderingContext.getDrawingBufferSize() to determine the width
and height of the back buffer, the rendered output will look "pretty
good" in the case where the drawing buffer couldn't be resized to
match the user's request. I'm agreeing with your original position
>>> That wouldn't be the case here. I agree that asynchronous handling of the event would be problematic. But I still think we should fail and have a function call which tells whether or not the drawing buffer is valid. That allows synchronous handling.
>> The author can determine whether the WebGL context failed to resize to
>> the given dimensions by seeing whether the canvas's width or height
>> are unequal to the drawing buffer's width or height. It sounds to me
>> like the best behavior for web developers is the automatic scaling up
>> of the content rather than signaling an error and ceasing WebGL
> But I think the author who doesn't make those checks is going to be a lot more confused about incorrect rendering than getting no rendering and a clear error message.
Their rendering will look "mostly correct" -- likely truncated along
one or two edges. At this point I think this is better than no output.
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: