Not piping during add frame

[enricodeleo]

Hi!

I'm creating a gif with 30 frames (but it happens for fewer frames too) and I noticed that even if I'm piping the image encoder to an express response, the image becomes visible only when the encorder.finish is called. Do I have misunderstood the advantage of stream in this use case or is it unexpected?

[heikkipora]

The encoder emits data to the consumer stream (http response stream in your case) after every frame (from code comments: "The frame is not written immediately, but is actually deferred until the next frame is received so that timing data can be inserted.")

There's likely buffering on multiple points before the image data reaches the browser. Could it be that your gif is rather small and thus the buffers are flushed only at the end of the encoding process ?

[enricodeleo]

I tried some logging and even if each frame is added. The stream is ok and the browser starts downloading immediately but again, nothing until finish is called.

This happens with every kind of gif I tried to create (from flat color to background images) and quality.
The only variable that really matters is how much frames I ask the encoder to add. My understanding is that with stream the browser shouldn't wait for the (for example) 10th frame to start seeing the image. Am I wrong?

[heikkipora]

I was under the impression (too) that browsers would start GIF animation playback immediately, but now I cannot confirm that. It seems that all GIF files I can come up with only start playing after all data has been received.

[enricodeleo]

@heikkipora yes it's exactly what I meant before. I cannot understand if this is something I can ever get. It starts being sloppy when you add 30 or 40 frames. As far as you know, is there any way of (at least) make frame addition parallel? Something like gif.js does in the browser with workers?

[heikkipora]

Node.js is single-threaded so the answer is no (to being able to process the frames in parallel).

[enricodeleo]

@heikkipora, believe me, I know very well about that, that's because I was talking about workers :)

[heikkipora]

Good :-) On node.js side that would mean using the node.js cluster mechanism but it would a very complex solution for the problem.