W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2013

Re: [whatwg] Proposal: createImageBitmap should return a "Promise" instead of using a callback

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 19 Jul 2013 09:28:17 +1000
Message-ID: <CAHp8n2kMCHVp7HPUadkFa0qEUY7MVdFDQLHQaNHNq-BVuWncFA@mail.gmail.com>
To: WHAT Working Group <whatwg@whatwg.org>
Promises are new to browsers and people who have used them before have
raised issues about the extra resources they require. It may be a
non-issue in the browser, but it's still something we should be wary
of.

Would it be possible for the first browser that implements this to
have both implementations (callback and Promise objects) and use the
below code or something a little more complex to see how much overhead
is introduced by the Promise object and whether it is in fact
negligible both from a memory and execution time POV?

Silvia.


On Thu, Jul 18, 2013 at 8:54 AM, Ian Hickson <ian@hixie.ch> wrote:
> On Thu, 18 Jul 2013, Silvia Pfeiffer wrote:
>>
>> In this case you did remove the non-promise based approach - presumably
>> because it has not been implemented in browsers yet, which is fair
>> enough for browsers.
>
> Right.
>
>
>> However, for JS developers it means that if they want to use this
>> function, they now have to move to introduce a Promise model in their
>> libraries.
>
> Not really. You don't have to use the promise API for anything other than
> a callback if you don't want to.
>
> As in, if your code uses the style that the HTML spec used to have for the
> createImageBitmap() example:
>
>    var sprites = {};
>    function loadMySprites(loadedCallback) {
>      var image = new Image();
>      image.src = 'mysprites.png';
>      image.onload = function () {
>        // ... do something to fill in sprites, and then call loadedCallback
>      };
>    }
>
>    function runDemo() {
>      var canvas = document.querySelector('canvas#demo');
>      var context = canvas.getContext('2d');
>      context.drawImage(sprites.tree, 30, 10);
>      context.drawImage(sprites.snake, 70, 10);
>    }
>
>    loadMySprites(runDemo);
>
> ...then you can still do this with promises:
>
>    var sprites = {};
>    function loadMySprites(loadedCallback) {
>      var image = new Image();
>      image.src = 'mysprites.png';
>      image.onload = function () {
>        // only the comment from the snippet above is different here:
>        Promise.every(
>          createImageBitmap(image,  0,  0, 40, 40).then(function (image) { sprites.woman = image }),
>          createImageBitmap(image, 40,  0, 40, 40).then(function (image) { sprites.man   = image }),
>          createImageBitmap(image, 80,  0, 40, 40).then(function (image) { sprites.tree  = image }),
>          createImageBitmap(image,  0, 40, 40, 40).then(function (image) { sprites.hut   = image }),
>          createImageBitmap(image, 40, 40, 40, 40).then(function (image) { sprites.apple = image }),
>          createImageBitmap(image, 80, 40, 40, 40).then(function (image) { sprites.snake = image }),
>        ).then(loadedCallback);
>      };
>    }
>
>    function runDemo() {
>      var canvas = document.querySelector('canvas#demo');
>      var context = canvas.getContext('2d');
>      context.drawImage(sprites.tree, 30, 10);
>      context.drawImage(sprites.snake, 70, 10);
>    }
>
>    loadMySprites(runDemo);
>
> The promises are very localised, just to the code that uses them. But
> then when you want to use them everywhere, you can do so easily too,
> just slowly extending them out as you want to. And when two parts of
> the codebase that use promises touch, suddenly the code that glues
> them together gets simpler, since you can use promise utility methods
> instead of rolling your own synchronisation.
>
>
>> I'm just dubious whether they are ready for that yet (in fact, I have
>> heard that devs are not ready yet).
>
> Ready for what?
>
>
>> At the same time, I think we should follow a clear pattern for
>> introducing a Promise based API, which the .create() approach would
>> provide.
>
> I don't understand what that means.
>
>
>> I guess I'm asking for JS dev input here...
>
> Promises are just regular callbacks, with the synchronisation done by the
> browser (or shim library) rather than by author code. I don't really
> understand the problem here.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 18 July 2013 23:29:02 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:03 UTC