Re: [whatwg] HTMLCanvasElement toBlob Promise

Making toBlob return a promise is definitely in keeping with the rest of
the web platform, but it's easy to write a wrapper function to promisify
it. IMO toBlob is better than toDataURL since it is async so the image
encoding can happen off main thread, reducing jank. I don't know how easy
it is for existing implementations to change - is it easy to return a
promise if no callback is provided?

I don't see any need to change toDataURL - it's already inefficiently
designed by the fact it returns a data URL which will be bloated compared
to a blob. So toBlob is naturally the preferred option for efficiency.



On 17 March 2015 at 20:02, Garrett Smith <dhtmlkitchen@gmail.com> wrote:

> On 3/14/15, acmesquares . <acmesquares@gmail.com> wrote:
> > It would be great if there was a promise-based version of toBlob. Same
> > parameters as toDataURL, but return a Promise to a blob.
> > I use toBlob heavily with other promise APIs, and this one really stands
> > out as in need of modernization.
> >
> Hi Adria,
>
> toBlob:
> https://html.spec.whatwg.org/multipage/scripting.html#dom-canvas-toblob
> ...
>
> The disparity between toDataURL  - sync - and toBlob  - async - can be
> awkward to handle. How would you write it as a promise? I don't agree
> that a promise would make that better; IMO it would just move the
> place of the callback. Maybe you can offer more insight on it. You can
> use a callback in the enclosing scope for both, as an adapter for
> toBlob. For example, (I helped anonymously get this working): -
>
> https://github.com/coremob/camera/blob/master/vanilla/js/main.js#L339
>
> function getBlobFromCanvas(canvas, data, callback) {
>   if (canvas.toBlob) { //canvas.blob() supported. Store blob.
>   // (GS) This assignment is still a mistake; should result `undefined`
>     var blob = canvas.toBlob(function(blob){
>       data.photo = blob;
>       callback(data);
>     }, 'image/jpeg');
>   } else { // get Base64 dataurl from canvas, then convert it to Blob
>     var dataUrl = canvas.toDataURL('image/jpeg');
>     data.photo = util.dataUrlToBlob(dataUrl);
>     if(data.photo == null) {
>       console.log('Storing DataURL instead.');
>       isBlobSupported = false;
>       data.photo = canvas.toDataURL('image/jpeg');
>   }
>   callback(data);
>   }
> }
>
> A comment on comments:
> I generally initial my code review comments so that once all the
> issues have been resolved, the resultant code has as few explanatory
> comments as needed (deliberate omission of copyright notice is
> tantamount to professional fraud). This strategy leads to asking if
> there are any comments left, and helps motivate the removal of
> comments which leads to authoring code that is self-explanatory and
> well-named. It also avoids misleading comments, or situations where
> the code comments fall out of sync with what the code is actually
> doing, such as in the example above:- "//canvas.blob() supported.
> Store blob."
>
> This code comment review practice can be replaced by repo commit
> comments (stash/gitlab/github), but comments work great in email or
> other mediums such as this (despite contradicting articles
>
> http://www.thinkful.com/learn/javascript-best-practices-1/#Comment-as-Much-as-Needed-but-Not-More
> )
>
> But to get back to your `toBlob` promise idea, would you want it as a
> new method like `getBlob(mimeType, quality)`? But then what about
> toDataURL? Would you have that as a promise, too, or would you leave
> it alone?
>
> canvas.getBlob(mimeType, quality).then(callback, errback);
>  ~ vs ~
> var dataUrl = canvas.getDataURL(mimeType, quality);
> util.dataUrlToBlob(dataUrl, callback, errback);
>
> ?
> --
> Garrett
> @xkit
> ChordCycles.com
> garretts.github.io
> personx.tumblr.com
>

Received on Wednesday, 18 March 2015 00:31:21 UTC