[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] WebGL back buffer contents
On Wed, Jan 27, 2010 at 11:57 AM, Chris Marrin <email@example.com> wrote:
> On Jan 27, 2010, at 9:51 AM, Gregg Tavares wrote:
>> ...Rendering directly to the canvas is probably the most common case, and having that "just work" without special handling would IMO be better and probably cause less confusion in total. As long as it is documented that the viewport will change on resize I don't think it will be such a big problem. The 2d context clears all state on a resize and that has not cause so much problem.
>> I'm getting lost. If the canvas can not be resized except by user code then why does the viewport need to automatically be updated? I could see an argument if the browser could magically resize the back buffer but it can't. I just want to make sure the 2 resize cases are not getting confused.
> I agree. There's no reason to fiddle with the viewport implicitly, especially since the author may not have set the viewport to match the window (for instance, to maintain aspect ratio or render to a subview). I think we should leave it alone.
> A "size changed" event might not be a bad idea though. It would make it a bit easier to separate the code that changes the size from the code that has to respond and rerender the change. Not essential, but perhaps useful.
I don't think we should do something Canvas- or WebGL-specific here. A
per-element onresize event would be really useful but for some reason
the only one defined in HTML is on the Window object (AFAIK).
You are currently subscribe to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: