Re: Standardising canvas-driven background images

I can atest that this feature helped me to dramatically reduce the drag on
http://arena.net. The section header backgrounds are using canvas elements
to avoid touching the DOM during scroll events. I would really like to see
this feature finished and fully standardized. I will say I prefer being
able to use any arbitrary element as the background of another element
(-moz-element() ) but I understand that is probably less likely.

In any case +1 this!


- Matthew Robb

On Fri, Feb 20, 2015 at 10:51 AM, Ashley Gullen <ashley@scirra.com> wrote:

> Forgive me if I've missed past discussion on this feature but I need it so
> I'm wondering what the status of it is. (Ref:
> https://www.webkit.org/blog/176/css-canvas-drawing/ and
> http://updates.html5rocks.com/2012/12/Canvas-driven-background-images,
> also known as -webkit-canvas() or -moz-element())
>
> The use case I have for it is this: we are building a large web app that
> could end up dealing with thousands of dynamically generated icons since it
> deals with large user-generated projects. The most efficient way to deal
> with this many small images is to basically sprite sheet them on to a
> canvas 2d context. For example a 512x512 canvas would have room for a grid
> of 256 different 32x32 icons. (These are drawn scaled down from
> user-generated content, so they are not known at the time the app loads and
> so a normal image cannot be used.) To display an icon, a 32x32 div sets its
> background image to the canvas at an offset, like a normal CSS sprite sheet
> but with a canvas.
>
> -webkit-canvas solves this, but I immediately ran in to bugs (in Chrome
> updating the canvas does not always redraw the background image), and as
> far as I can tell it has an uncertain future so I'm wary of depending on
> it. The workarounds are:
> - toDataURL() - synchronous so will jank the main thread, data URL
> inflation (+30% size), general insanity of dumping a huge string in to CSS
> properties
> - toBlob() - asynchronous which raises complexity problems (needs a way of
> firing events to all dependent icons to update them; updating them requires
> DOM/style changes; needs to handle awkward cases like the canvas changing
> while toBlob() is processing; needs to be carefully scheduled to avoid
> thrashing toBlob() if changes being made regularly e.g. as network requests
> complete). I also assume this uses more memory, since it effectively
> requires creating a separate image the same size which is stored in
> addition to the canvas.
>
> In comparison being able to put a canvas in a background images solves
> this elegantly: there is no need to convert the canvas or update the DOM as
> it changes, and it seems the memory overhead would be lower. It also opens
> up other use cases such as animated backgrounds.
>
> I see there may be security concerns around -moz-element() since it can
> use any DOM content. This does not appear to be necessary or even useful
> (what use cases is arbitrary DOM content for?). If video is desirable, then
> video can already be rendered to canvases, so -webkit-canvas still covers
> that.
>
> Therefore I would like to propose standardising this feature based off the
> -webkit-canvas() implementation.
>
> Ashley Gullen
> Scirra.com
>