Re: [whatwg] HTMLCanvasElement toBlob Promise

On 3/18/15, acmesquares . <acmesquares@gmail.com> wrote:
> Admittedly a wrapper function is trivial, mostly for API consistency, and
> does simply move the callback elsewhere.
>

There is a lot of room for improvement for toBlob.

> However that's not unprecedented as Navigator.mediaDevices.getUserMedia()
> was just a promisification of an existing API.
>

I did not know there was in-place promisification of gUM, but here it is:-
http://w3c.github.io/mediacapture-main/getusermedia.html#dom-mediadevices-getusermedia

The original non-promise version is still documented on MDN as of today:-
 https://developer.mozilla.org/en-US/docs/Web/API/Navigator/getUserMedia


> Nor is the alternative since OfflineAudioContext.startRendering is being
> superseded by a Promise version in-place.
>
>
They really went overboard there with promises on the new draft. I
wonder what will break from those changes.


My gut tells me two things 1) The canvas API (for toBlob, toDataURL)
should have been fixed years ago: 2) don't break the web.

I usually am pretty conservative about not breaking the web. But now
that I'm looking at crumb camera code again, and that API, you're
right (and Adria too). How much would break if toBlob is changed to
return a promise?

>  Personally I monkey patched a new method toBlobPromise, and use that to
> the total exclusion of the original. It's unavoidable when using
> Promise.all() anyway.
>

What are you building?

I used if-else and a callback function to work around the
toDataURL/toBlob sync vs async paths. I'm not particularly proud of
the code, but I will say that the quality of the toBlob/toDataURL API
is reflected in it.

In fact, I was not happy about it when I wrote it and I had other
complaints about the canvas methods (still do). But because I wasn't
an official member of the Nokia project, it would have been out of
place for me to submit a bug re that, and potentially would have had
ramifications, with her employer wondering about the extend of my
help, or why I am filing a bug and providing examples of a project
that I wasn't on. And she did not want to file a bug or provide
feedback, though I offered to help with both of those. The problems
with the canvas API should have been addressed then. But as we can
see, it has been sitting there rotting with no feedback for over two
and a half years, and apparently only Firefox implements it, is that
right?


Chromium Issue 67587:	Add toBlob to Canvas element.
https://code.google.com/p/chromium/issues/detail?id=67587


> Actually on initial encounter, I'd be least surprised if toBlob did return
> a 'promise which resolves with a Blob'. Just like Fetch API Body.blob()
>

OK, so it seems intuitive to you to have it be designed with a promise.

My gut tells me don't break the web by changing existing behavior. And
I don't care about promises much.

The toBlob algorithm has problems. If it is to be redesigned, it
should address these problems: The formal parameters are missing, it
accepts variable arguments, some those arguments are passed through.
The pass through arguments are passed through as a variable
ambiguously named named `arguments`, there is no type checking to see
if the callback is callable, only to make sure that it is not `null`,
in the middle of the algorithm, there is a step that says "return, but
continue", there are two additional parallel processes steps: Step 6
begins in parallel and step 7 kicks off a new task with "Queue a
task".

There is an internal method named " a serialisation of the canvas
element's bitmap as a file" for which no parameter variables are
specified and in lieu of that, the note "optionally with some given
arguments,"

I can think of many ways this could be redesigned and respecified.

https://html.spec.whatwg.org/multipage/scripting.html#dom-canvas-toblob


If you want to have a stab at a better redesign, I think that's a great idea.

>
>  Regarding existing implementations, Mozilla implemented in core in Feb
> 2013, and moved processing off main-thread Feb 2014. Webkit deferred to
> Chromium which never finished implementation, so usage in the wild will
> have been heavily impeded, and would necessarily fall back on toDataURL.
> Jankiness is the least concern given this function can easily crash the
> context.
>

That's useful to know. Always good to have an idea of what the
consequences are before we go and break it.

> Since the spec is converging on Canvas-in-Worker (transferable ImageData,
> DOM independent CanvasRenderingContext2D etc), I'd also consider how to get
> my Blob image representation inside a Worker.
>
>
>  I probably shouldn't have dragged toDataURL into this, but in response I'd
> avoid using it. A function which returns either dataURL or Blob is useless
> as no other API speaks dataURL. If forced for legacy reasons I'd probably
> convert using FileReaderSync.readAsDataURL( blob )
>

Having a mix of sync/async is confusing.
-- 
Garrett
@xkit
ChordCycles.com
garretts.github.io
personx.tumblr.com

Received on Tuesday, 28 April 2015 06:55:03 UTC