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