[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 Nov 9, 2010, at 1:38 AM, Cedric Vivier wrote:
> On Tue, Nov 9, 2010 at 14:18, Gregg Tavares (wrk) <email@example.com> 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,
> definitely not.
>> 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).
First of all, let me say that I think the "stretching the window across 9 displays" case is a degenerate case and I don't think we should optimize the solution for it. So the question of preserving aspect ratio or not is a much more minor issue in my mind. Do we agree that attempting to create a drawing buffer that is too large DOES NOT generate an error, but rather creates a drawing buffer that fits within the system constraints, and makes that information known to the author by some sort of getDrawingBufferSize() call? If we can agree on that, we've solved most of the problem. In fact, we could always make the dimensions chosen be platform dependent.
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: