Closed leeoniya closed 11 years ago
I'd be intereseted in a streaming version too, so you can do e.g.
http.createServer(function (req, res) {
var stream = new GifStream();
stream.write(imgData1);
setTimeout(function () {
stream.write(imgData2);
stream.end();
}, 500);
stream.pipe(res);
});
This way you can do GifSockets! https://github.com/videlalvaro/gifsockets
i'm starting to realize most of the functionality i opened issues for already exist in the base encoder this library uses https://github.com/antimatter15/jsgif
i'm not quite sure what this lib adds on top of that and find it a bit disingenuous that it is not mentioned in the main README as providing virtually all the functionality for this project. i just used the jsgif
lib to stream my frames to it, and it worked out great. closing this.
If you have a look at the source files i clearly state that the encoder is a port of Thibault Imbert's as3 version.. which in turn is a port of Kevin Weiner's java classes you can find at http://www.java2s.com/Code/Java/2D-Graphics-GUI/AnimatedGifEncoder.htm
I made my own ports of the base classes a year back after not being happy with the performance of antimatter15's version, which at the time just where Thibault Imbert's as3 version with the types commented out (and still is by the looks of it).
NeuQuant.js i ported directly from Anthony Dekker's C version you can find at http://members.ozemail.com.au/~dekker/NEUQUANT.HTML
I put a lot of effort in to this library and it really sucks to have it called a copy. I hope this clears things up.
i apologize for my comment coming off this way, i did not do an extensive comparison but saw a lot of files named the same way in both sources. after doing a diff on them i see there was a significant amount of work put into them all. i appreciate that you have added the project references to the readme as well. i will reopen this and wait for updates. thanks!
as for this bug, i think accepting a Context2d or ImageData or pseudo-imagedata as in antimatter15's version is ideal. the working code i have with that version is:
var encoder = new GIFEncoder();
encoder.setRepeat(0); // auto-loop
encoder.setDelay(20);
encoder.start();
trc.draw(100, function() {
encoder.addFrame(this.lyrs[0].ctx);
}, function() {
encoder.finish();
document.getElementById('image').src = 'data:image/gif;base64,' + encode64(encoder.stream().getData());
});
trc
is an instance of my tracing stack, 100
is ops/sec, first function is onFrame
callback, second is onDone
callback.
Ok :)
Is that example asynchronous? I think a quick solution to this problem would be to simply add a option to have addImage copy the data from the ctx for later.
Modeling the encoder as a stream is really interesting though, i'll have a look at that when i get some free time
no, that's not async. but it does copy whatever you pass in as the frame. it would be good if your lib accepted ImageData and Context2d as frames, not just a canvas element or image element (both of which actually seem like secondary use-cases rather than primary)
Now it checks for CanvasRenderingContext2D
instances, and i added an option to copy the data also.
would it be possible to have gif.js operate as a frameclient? (http://en.wikipedia.org/wiki/Frameserver)
i have a canvas animation that uses a single canvas element to draw separate frames. since
gif.addImage
does not extract ImageData when called, it is impossible to utilize different frames from the same canvas element. alternatively,.addImage
can be made to accept extracted ImageData as well.it would likely be easy, but memory-hungry to hold the imageData of all frames until
.render()
is called, but if the frame processing can be made eager instead of lazy, then a frameserver can stream frames from the same canvas element with the overhead dictated instead by worker count, cpu speed, encoder efficiency and config.thanks!