W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2013

Re: [whatwg] Challenging canvas.supportsContext

From: Benoit Jacob <jacob.benoit.1@gmail.com>
Date: Wed, 19 Jun 2013 14:25:17 -0400
Message-ID: <CAJTmd9p_P6DGM_ACyvO0BrQ+sTFdoBt+L6QYpwxfuT_FPeRnhA@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: WHATWG <whatwg@lists.whatwg.org>
2013/6/19 Tab Atkins Jr. <jackalmage@gmail.com>

> On Wed, Jun 19, 2013 at 11:17 AM, Benoit Jacob <jacob.benoit.1@gmail.com>
> wrote:
> > So let's look at the naive application usage pattern for supportsContext:
> >
> >   if (canvas.supportsContext("webgl")) {
> >     context = canvas.getContext("webgl");
> >   }
> >
> > The problem is that the same can be achieved with just the getContext
> call,
> > and checking whether it succeeded.
>
> The problem that supportsContext() solves, and which was brought up
> repeatedly during the drive to add this, is that spinning up contexts
> can be expensive.
>

I tried to address this very argument in my above email; maybe I wasn't
clear enough.

1. If supportsContext() fails, then getContext() fails just as fast. In
that case, supportsContext isn't any faster.
2. If supportsContext succeeds, then the application is going to want to
proceed with calling getContext, so nothing is achieved by supportsContext
being cheaper than getContext.

If you disagree with that argument, then I would like, again, to hear about
what would be an application use case that actually benefits from
supportsContext.

Benoit
Received on Wednesday, 19 June 2013 18:25:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:22 UTC