[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, Nov 9, 2010 at 14:18, Gregg Tavares (wrk) <firstname.lastname@example.org> wrote:
> 1) Leave it as is. App gets an exception or lost context or something along
> those lines. Most apps won't handle this and will effectively stop
> functioning until the page is refreshed and even then, only if the user
> resizes the page small enough
A lost context looks good enough to me, especially for 1.0, exactly
like we aren't trying to restore context automatically at all cost
just for the sake of displaying something.
This is a good way to reduce the number of "failure paths", which
ultimately helps testability and will increase reliability of WebGL
apps in general.
> 2) Make it as large as possible and stretch. Most apps won't handle this
> case either but at least they won't stop functioning.
If you define "functioning" as displaying something that is possibly
garbage (eg. Steve's example), then yes.
If we define "functioning" as displaying something that looks more or
less closely to what was intended AND that can be manipulated
(changing aspect ratio and backbuffer dimension does also impact mouse
control and/or object picking - not only rendering!), then no,
> The debate here seems
> to be whether they should shoot for the same aspect ratio as originally
> requested or not. I'm on the "not" side.
Preserving aspect ratio is probably a much safer bet to make this
feature more useful than harmful imho (though it still can cause
non-rendering related issues).
Maybe we should make a test build hardcoded to randomly downsize the
backbuffer to arbitrary non aspect-ratio preserving dimensions and see
whether or not it breaks current public WebGL content in many
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: