[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 Tue, Sep 28, 2010 at 1:30 PM, Chris Marrin <cmarrin@apple.com> wrote:
>
> On Sep 28, 2010, at 11:45 AM, Kenneth Russell wrote:
>
>> On Mon, Sep 27, 2010 at 10:02 AM, Chris Marrin <cmarrin@apple.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.
>
> 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
CanvasRenderingContext2D.getImageData().

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

-Ken

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