[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 Fri, Sep 24, 2010 at 4:10 PM, Kenneth Russell <firstname.lastname@example.org>
If the author has already fetched a WebGLRenderingContext from the
On Fri, Sep 24, 2010 at 8:58 AM, Chris Marrin <email@example.com
> I've read over the thread and I agree that we can't hide the actual size from the author. But I don't think we can change canvas.width and canvas.height either. Read/write attributes in the DOM are typically not changed by the system from what the author set. It might even be prohibited in the DOM spec.
> If so, I think we can deal with it cleanly. We already have a context error event which we can use to notify the author that the context could not be created and we can indicate that it was because the size was too large and return the max width and height so the author can make another try. We can also specify a minimum supported canvas size (1024x1024 or something) so authors can avoid having to handle the event if they stay within that size.
canvas before resizing it then this would need to be a context lost
event, not a context creation error event.
Despite the fact that delivery of this event is traumatic to the app,
I still think it's the option that best fits within the current canvas
and WebGL semantics.
Real GL doesn't give you lost context in this case AFAIK, It just fails to make the new buffer. Why should WebGL be any different?
Do we really want if a window gets sized a little to large the app dies? What other HTML thing does this?