[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 11:54 AM, Oliver Hunt <email@example.com> wrote:
> On Sep 28, 2010, at 11:45 AM, Kenneth Russell wrote:
>> 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.
> Sorry, this made me wonder if something has changed recently -- Originally the behaviour of the ewbgl context was meant to be identical to that of the 2d context: the width/height attributes of a canvas only effect the size of the buffer, the onscreen size of the canvas is determined by css rules applied to the element. The default css size for a canvas element is the pixel size of the buffer, but other than that they are not necessarily correlated. Has this changed?
Nothing has changed. Tab pointed out that it is legal for a canvas to
have a higher-resolution backing store than the actual canvas size
(width/height). The only situation in which this would be apparent to
the app developer is during CanvasRenderingContext2D.getImageData().
> That said i have a slight concern about silently choosing a different size for the buffer, and that is what happens if the app calls readPixels after a different sized backing store was chosen.
Do you have another suggestion? Of the available alternatives this
looks the best to me.
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: