closes #253

Also addresses: #84

@gamburgm @vishesh I'm having problems making bitmap/url in 2htdp/image fetch images asynchronously (images get rendered in wrong order, or something wrong with the image object where it cant find render function)

Any ideas? Do I need to change the big-bang loop to be more amenable to asynchronous execution?

Codecov Report

Merging #293 (cd1933f) into master (d2dc0ba) will increase coverage by 0.14%.
The diff coverage is 81.25%.

@@            Coverage Diff             @@
##           master     #293      +/-   ##
==========================================
+ Coverage   68.16%   68.30%   +0.14%     
==========================================
  Files          48       48              
  Lines        5308     5354      +46     
==========================================
+ Hits         3618     3657      +39     
- Misses       1690     1697       +7     

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d2dc0ba...cd1933f. Read the comment docs.

Unfortunately I think you'd have to fully commit to using async in big-bang; that is, you can't have individual 'renderable components' that are async, you want all of them to be.

.then prevents deterministic evaluation of promises unless you're able to chain them, which would mean CPS-ing a large chunk of image.rkt and universe.rkt, probably not ideal.

EDIT: .then, in this case, actually is deterministic -- promises are evaluated in FIFO order (once they start executing), which is why the nested place-image calls manage to render the images in reverse order.

The alternative is to make every render function async, and await every recursive render call. You can cut off the coloring effect in to-draw, and just call .then on the resulting promise from img.render with a thunk, or just leave it alone (I forget which is correct off the top of my head).

A little unfortunate though that you'd have to make such a significant change just to allow for async. For what it's worth, I'd guess that the async version is the more performant one in the typical case, since lots of promises (especially if they just get awaited) don't incur a large overhead and fetching images or handling other I/O in the background is a big win.

Let me know if the above makes any sense.

That's what I was afraid of. Makes sense though, thanks. I'll keep it in mind, in case someone is looking for a small project.

Just pushed something that seems to "work".

It makes the big-bang setup step async, and then doesnt call the start method until everything is ready.

I then added a ready method to the async imgs, which gets called in setup.

One weird thing is that I couldnt find a good place to save the async objs that need resolving so right now it's just a global array in jscommon.rkt. Is there a more idiomatic way to do this in js?

You can play around with it if you want:

• no async image loading: http://play.racketscript.org/#example/archery
• with async image loading: http://dev.racketscript.org:8080/#example/archery

If you compare the network tab in the browser for each one the async one seems a little faster, but I need to come up with some more stressful tests

I think idiomatic javascript would look pretty different:

• bitmap/url returns a promise
• the functions that compose images (e.g. place-image) also return one promise that resolves the child promises
• big-bang just awaits the one promise it needs to at the end

which gives the added benefit of not having to wait for images to load at the beginning that aren't needed until later (or needed at all).

I can't think of a better solution than this of the top of my head without coloring all the functions async.