[whatwg] Hardware accelerated canvas

David Geary david.mark.geary at gmail.com
Tue Sep 4 10:25:10 PDT 2012


On Tue, Sep 4, 2012 at 11:12 AM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

> On Tue, Sep 4, 2012 at 10:07 AM, David Geary <david.mark.geary at gmail.com>
> wrote:
> > On Tue, Sep 4, 2012 at 10:53 AM, Boris Zbarsky <bzbarsky at 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.


david


>
> ~TJ
>



More information about the whatwg mailing list