On Fri, May 9, 2014 at 5:51 PM, Ian Hickson <i...@hixie.ch> wrote:

> On Thu, 18 Jul 2013, Justin Novosad wrote:
> > However, one weakness of the current API is that upon construction of
> > the ImageBitmap, the browser does not know whether the asset will be
> > used with a GPU-accelerated rendering context or not. If this
> > information were available, the asset could be pre-cached on the GPU
> > when appropriate.  Maybe something like ctx.prefetch(image) would be
> > appropriate for warming up the caches.
> Is this a measurable performance problem currently? I'd hate to provide
> such an API, which could easily be misunderstood or misused, only to find
> that in practice things already work ok.

Agreed. A slower first draw is often tolerable. And the performance hit of
a GPU texture upload is usually quite small relative to decode, disk cache
access and network access.

> On Fri, 19 Jul 2013, Justin Novosad wrote:
> >
> > A related issue we have now is with canvas backing stores. It is common
> > for web apps to create temporary canvases to do some offscreen
> > rendering. When the temporary canvas goes out of scope, it continues to
> > consume RAM or GPU memory until it is garbage collected. Occasionally
> > this results in memory-leak-like symptoms.  The usual workaround is to
> > use a single persistent global canvas for offscreen work instead of
> > temporary ones (yuck).  This could be handled in a cleaner way if there
> > were a .discard() method on canvases elements too.
> Would setting the canvas dimensions to zero have the same effect?

Absolutely. And I have given that tip to devs many times. It is just that
finding that trick is non-obvious to a dev who is unaware of how the
browser is implemented internally, which is usually the case.

We could have a method that just sets the dimensions to zero, if so, and
> if this is common enough to warrant a convenience method.

Yes. A dispose() would feel less hacky and developers would find it more

> > 5) Once a large image is decoded and downsampled into a smaller
> > ImageBitmap, the only thing that we can do with that ImageBitmap is to
> > copy it into a Canvas, either for display to the end user (as an
> > alternative to an <img>) or for re-encoding with Canvas.toBlob() (when
> > creating thumbnails for large images). The motivation for this
> > downsampling feature is memory use. But having to copy an ImageBitmap
> > into a canvas in order to use it immediately doubles the amount of
> > memory required. So for this reason, I also want to propose that
> > ImageBitmap have a transferToCanvas() method akin to the
> > transferToImageBitmap() and transferToImage() methods proposed at
> > http://wiki.whatwg.org/wiki/WorkerCanvas.  transferToCanvas would
> > transfer the image data into a new Canvas object and would neuter the
> > ImageBitmap so that it could no longer be used.
> This is an interesting idea. I don't know what the state of the other
> methods discussed here is (see my comment at the top of the e-mail cited
> above). However, I've filed a bug for this too:
>    https://www.w3.org/Bugs/Public/show_bug.cgi?id=25647
> I think what might make the most sense here is to have a way to
> destructively convert an ImageBitmap into an <img>, rather than doing
> anything with a canvas.

What would go in the 'src' attribute of the image element? A a data URL?

> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Reply via email to