On Thu, 12 May 2011, Cedric Vivier wrote:
>
> Thanks for your thorough reply and overview of the issue.
>
> In case it slipped through your inbox, I've posted a more up-to-date
> (wrt WebGL WG discussions) and actionable proposal at :
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-Ma
On Thu, May 12, 2011 at 2:42 AM, Ian Hickson wrote:
> On Wed, 13 Apr 2011, Glenn Maynard wrote:
> > Calling canvas.getContext("webgl", {async: true}) will cause it to
> > discouraged from using this API (deprecating it if possible).
>
(FYI: while some people have expressed interest in async init
To summarise this thread:
WebGL has the unfortunate problem of being likely to run into hardware
limitations more often that most other features, due to limited GPU
resources. Authors need to be able to distinguish the temporary failure of
a context not being immediately available from the perm
I forgot that this was all still going to whatwg, instead of public-webgl.
We may want to move there.
On Thu, Apr 14, 2011 at 12:33 AM, Glenn Maynard wrote:
> On Wed, Apr 13, 2011 at 9:01 PM, Kenneth Russell
> wrote:Return a new object for contextId
>
> > Adding support for asynchronous initia
On Wed, Apr 13, 2011 at 9:01 PM, Kenneth Russell
wrote:Return a new object for contextId
> Adding support for asynchronous initialization of WebGL is a good
> idea, and should be proposed on public_webgl, but this discussion
> should focus solely on improving the specification of the existing
> sy
On Thu, Apr 14, 2011 at 09:01, Kenneth Russell wrote:
> Adding support for asynchronous initialization of WebGL is a good
> idea, and should be proposed on public_webgl, but this discussion
> should focus solely on improving the specification of the existing
> synchronous initialization path, and
On Wed, Apr 13, 2011 at 4:43 PM, Glenn Maynard wrote:
> On Wed, Apr 13, 2011 at 4:21 PM, Kenneth Russell wrote:
>>
>> It's essential to be able to report more detail about why context
>> creation failed. We have already received a lot of feedback from users
>> and developers of popular projects l
On Wed, Apr 13, 2011 at 4:21 PM, Kenneth Russell wrote:
> It's essential to be able to report more detail about why context
> creation failed. We have already received a lot of feedback from users
> and developers of popular projects like Google Body that doing so will
> reduce end user frustrati
On Wed, Apr 13, 2011 at 05:16, Kenneth Russell wrote:
> (...)
> To sum up, in general I think that whenever getContext("webgl")
> returns null, it's unrecoverable in a high quality WebGL
> implementation.
Makes sense.
Applications could detect all possible context creation failure
scenarios with
On Tue, Apr 12, 2011 at 4:32 PM, Glenn Maynard wrote:
> Based on some discussion[1], it looks like a clean way to handle the
> "permanent failure" case is: If the GPU is blacklisted, or any other
> permanent error occurs, treat "webgl" as an unsupported context. This means
> instead of WebGL's co
Based on some discussion[1], it looks like a clean way to handle the
"permanent failure" case is: If the GPU is blacklisted, or any other
permanent error occurs, treat "webgl" as an unsupported context. This means
instead of WebGL's context creation algorithm executing and returning null,
it would
On Tue, Apr 12, 2011 at 2:21 AM, Boris Zbarsky wrote:
> On 4/12/11 12:06 AM, Ian Hickson wrote:
>>>
>>> Now, that's a problem for WebGL, because it's not possible to tell in
>>> advance whether the underlying rendering context can be created.
>>
>> It would be helpful if someone could explain what
On 4/12/11 12:06 AM, Ian Hickson wrote:
Now, that's a problem for WebGL, because it's not possible to tell in
advance whether the underlying rendering context can be created.
It would be helpful if someone could explain what conditions could lead to
a situation where getContext() could fail to
On Mon, 11 Apr 2011, Glenn Maynard wrote:
>
> Now, that's a problem for WebGL, because it's not possible to tell in
> advance whether the underlying rendering context can be created.
It would be helpful if someone could explain what conditions could lead to
a situation where getContext() could f
To confirm the fundamental problem: Canvas.getContext (and the corresponding
"Return a new object for *contextId*" algorithm) can never return null.
http://krijnhoetmer.nl/irc-logs/whatwg/20110412#l-209
It's intended that calling getContext on a supported context *always* return
a context; it
On Sat, Apr 9, 2011 at 7:55 PM, Glenn Maynard wrote:
> getContext doesn't specify error handling. WebGL solves this oddly: if an
> error occurs, it dispatches an event with error details at the canvas. It's
> odd for a synchronous API to report error information with an event; it
> would make a
getContext doesn't specify error handling. WebGL solves this oddly: if an
error occurs, it dispatches an event with error details at the canvas. It's
odd for a synchronous API to report error information with an event; it
would make a lot more sense to raise an exception. However, getContext
doe
17 matches
Mail list logo
