Add two demos using streams for PNG manipulation

[ksm2]

I added two demos I wrote for MDN to the list of your demos, if you'd like!

[ricea]

Great stuff!

• I'd like GrayscalePNGSource to be a transform stream. Wrapping a ReadableStream inside another ReadableStream is a pattern I'm trying to discourage. I realise the fact that no browser has shipped TransformStream yet makes this inconvenient! If it's not possible to change this, could we link only to "Unpack chunks of a PNG" for the time being?
• In logReadableStream(), it would be much easier to create a WritableStream and then pipe to it. Basically the contents of pump() would instead be in the write() method, except for the if (done) part which would go in the close() method. Try it, I think you'll like it!

As a general rule, any time you're using getReader() or getWriter(), you should think about whether there would be a simpler way to do it with pipeTo() or pipeThrough().

General comments:

• It looks like GrayscalePNGSource won't work properly unless the input is an rgba PNG. Maybe it should throw in other cases?
• Using

const {value, done} = await reader.read();

inside a loop in an async function is much easier and cleaner that using a pump() function. I think all the browsers that have or will have ReadableStream already support async/await.

It took me a while to understand what "Unpack chunks of a PNG" was doing. It would probably benefit from a bit more documentation.

[ksm2]

I have seen TransformStream in the spec, but without the browser support I felt not encouraged enough to build the whole demo against it if I cannot test the result in at least Chrome. Is there some kind of shim I could use to patch TransformStreams to browsers which support ReadableStream and WritableStream?

You could not make me happier with your statement about async/await! Actually, I wrote the whole code with async functions first as I am a huge fan of the concept – but MDN disapproved it fo being to complex to newbies of ES6+. (Actually, in the case of streams, I hope for for-await-of to enter ECMAScript as this would be the easiest way to iterate over a ReadableStream IMHO.)

Should I make the code changes here in the spec's repository in the demo directory? I also just filed a PR against MDN's repository. I am not shure they support changes there.

[ricea]

I have seen TransformStream in the spec, but without the browser support I felt not encouraged enough to build the whole demo against it if I cannot test the result in at least Chrome. Is there some kind of shim I could use to patch TransformStreams to browsers which support ReadableStream and WritableStream?

It's available in Chrome with the experimental web-platform-features flag enabled: chrome://flags/#enable-experimental-web-platform-features

It will hopefully be turned on by default in version 67.

https://streams.spec.whatwg.org/demos/transforms/transform-stream-polyfill.js is the outdated but mostly compatible polyfill used by the demos linked from the standard.

Actually, in the case of streams, I hope for for-await-of to enter ECMAScript as this would be the easiest way to iterate over a ReadableStream IMHO.

Hopefully you'll be able to use this sooner rather than later: #778

Should I make the code changes here in the spec's repository in the demo directory? I also just filed a PR against MDN's repository. I am not shure they support changes there.

If we cannot find a compromise with MDN then that would be my preference, yes.

[ksm2]

If we cannot find a compromise with MDN then that would be my preference, yes.

Hey @ricea, the folks at MDN merged my updates now using TransformStreams!

[ricea]

Could you update this comment to indicate that it uses TransformStream?

Also, in the demo itself, it would nice if it displayed a message in the page when TransformStream is not defined, to avoid confusion.

[ricea]

We don't need to block this on the changing http://mdn.github.io/dom-examples/streams/grayscale-png/. The MDN people might not agree to that anyway.