[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 Mon, Nov 8, 2010 at 4:52 PM, Cedric Vivier <cedricv@neonux.com> wrote:
> On Mon, Nov 8, 2010 at 23:24, Chris Marrin <cmarrin@apple.com> wrote:
>>> For instance, outside of pure WebGL related issues, such a resize may
>>> significantly change how mouse controls work if not taken into account
>>> ... typically relative mouse motion/position is given related to
>>> canvas dimensions [manually or by libraries such as jQuery]. Even so,
>>> handling it might make the application unusable anyways because of the
>>> great loss in horizontal precision in rendering.
>> Such a scenario would require the author to realize that the buffer is not the requested size and adapt the code accordingly. I don't think that's a bad scenario.
> In theory, yes. However I don't find realistic to expect all (or even
> most) WebGL authors and general-purpose Javascript libraries to
> complicate their control handling (among other more WebGL-ish
> concerns) for the unlikely and non-obvious event of back buffer
> resizing. Even if they try to do so, it might be impossible for some
> apps to deal in a user-friendly way with such arbitrary loss of
> precision in only one dimension (eg. a FPS game).
> I fear that instead of improving user experience, prioritizing
> "display something at all costs" over "display as developer intended"
> will give many inconsistent/undesirable results and add burden on all
> WebGL developers for something that could be better handled on a
> case-per-case basis as they see fit (including, of course, by WebGL
> libraries).
> At worst, this automatic backbuffer downsizing feature should relate
> to a new member in WebGLContextAttribute so that it can be disabled
> and overridden by other mechanisms.


We are talking about an error condition here, where the WebGL
implementation simply can not honor the requested size that was
requested by the developer.

Providing an option to change the behavior in this error condition
between being handled automatically and being a synchronous error
condition is far worse than choosing one of those two behaviors and
being consistent.

Your earlier assertion that we should handle this condition
automatically but preserve the aspect ratio of the canvas is
inconsistent with your assertion that the behavior should optionally
synchronously generate an error condition.

I continue to agree with Tab Atkins, who works on the Canvas spec and
has extensive experience developing Web APIs, that it is better to
display some content than no content. I also believe that in this
error condition the implementation should perform the semantically
simplest adjustment to the back buffer size possible: clamping to
implementation-defined maximums.

We need to resolve this issue quickly to get the spec to version 1.0.
I hope that you will agree with me that the behavior I've outlined
above is acceptable.

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: