W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2012

Re: [whatwg] Hardware accelerated canvas

From: David Geary <david.mark.geary@gmail.com>
Date: Tue, 4 Sep 2012 11:25:10 -0600
Message-ID: <CA+44zngNoiY8DrkF5zMCbRLb++d92shMqpLxfVo7x4qPrrc+_g@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: whatwg@lists.whatwg.org, Boris Zbarsky <bzbarsky@mit.edu>
On Tue, Sep 4, 2012 at 11:12 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Tue, Sep 4, 2012 at 10:07 AM, David Geary <david.mark.geary@gmail.com>
> wrote:
> > On Tue, Sep 4, 2012 at 10:53 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> >> Ms2ger points out (without endorsing) that there's an:
> >>
> >> 8)  Have every author who wants their canvas to stick around call
> >> toDataURL() and stick the result in an <img src>.
> >
> > And then the browser presumably uses the img to regenerate the canvas on
> a
> > lost context? Why not just give developers a callback and let them
> restore
> > the canvas as they see fit?
> No, the author just uses the <img> in their page instead.  The
> <canvas> is only used in JS to generate the image, and is never put
> into the document at all.

Ah, okay. Thanks for the clarification.

> And again, the reason that "just give them a contextloss event" is bad
> is because most people simply won't do it.  It doesn't make any sense!
>  The browser just... forgets about your image, which it was displaying
> fine just a second ago?

If you tell developers they have to use toDataURL() to create an image for
static canvases, then you're going to have to tell them why. And then
you're back to square one.

That's what I meant by most of Boris's solutions being at the wrong level
of abstraction. Solving the problem at a higher level of abstraction to
obfuscate the real reason is a mistake, IMO, even when the reason may not
make apparent sense. I believe developers are pretty smart, and will be
able to make sense of it.


> ~TJ
Received on Tuesday, 4 September 2012 17:33:50 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:45 UTC