Prototype GIF library #2747
Prototype GIF library #2747
Conversation
|
Wow I didn't know there was a "work in progress" feature in git. Pretty sure I've never seen that before, although I've seen plenty of works in progress. :) I don't think there's one correct abstraction, especially about timing. For your tree example, you want every MOVE to trigger a snapshot. Depending on the purpose, you might also want every TURN to trigger one. (No for a demo, yes for a lesson about recursion and fractals.) So I would be inclined to do your upvar thing (but what I really really want is an up-block feature, so the user wouldn't have to know about RUN), but also have two Boolean inputs for snap-on-move and snap-on-turn, maybe defaulting to on and off. From sad experience: Stick ten or twenty copies of the first frame in front, and ten or twenty copies of the last frame at the end, especially the latter. Otherwise people get confused about the animation, especially if they haven't seen any such computational process before. Or, maybe even ten or twenty empty frames after the final one. And yeah, you have to fix the retina bug, because Jens has already hidden that checkbox and keeps threatening to remove it altogether. The difficult decision is whether you should scale down by half in retina mode. If not, your gif will take up a gargantuan amount of screen space, but if so, you lose a little beautiful sharpness. |
|
What am I doing wrong? |
|
Might be that race condition. Try sticking a "wait 1 sec" in your for loop for now. Also, you probably want the "snapshot" block to be inside the loop. |
|
Never mind; the helper .js has to be in libraries; I tried just pulling gif.xml into my project. Duh. |
|
I hate my life. |
|
You have to serve the files from a server! (For security reasons.) Even localhost will do. |
|
Very nice, thanks, @kach ! Instead of a whole mechanism spread out over 3 command blocks I think I'd much prefer one single block, either a reporter or - perhaps better here - a command that takes a list of costumes as input and produces an animated GIF from that. Additional parameters should probably be the frame rate and the dimensions of the output GIF and perhaps others, such as whether the GIF is looping, which kind and level of compression, color palette and reduction etc. etc. For starters we could leave out the more "advanced" parameters and only offer framerate and dimensions. That would also take care of retina issues. But the main suggestion from me is to use Snap's lists of costumes for this, and not to implement a separate container mechanism. Does that make sense? Oh, if you're going to go with my list-of-costumes suggestion you'd probably want to guard against costumes of different dimensions. But you'd have to do this anyway, even in your current architecture. What do you think? |
|
If it uses a list of costumes, it becomes a bit harder to make an animation like Kartik's tree. Either version can be written in terms of the other, of course, but the library should provide tools for both cases without the user having to deal with the boring parts. As for all those "additional parameters" you want, who are you really and what did you do to Jens? You always yell at people who want a zillion parameters to, e.g., the WRITE block. A reporter would be great if only we supported animated costumes, but since we don't, all we can do with the gif is export it. So it might as well be a command. If you put a non-looping gif in a web page, does it just do the animation right away, before the user is even looking at it? Or would it run when clicked? I'm leaning toward saying it should always be looping. I think a fixed frame rate is okay, maybe just a hair slower than Kartik's example. As for the dimensions, the really right thing is that when about to export, look for pixels that are transparent all the way down, including the background layer, and if there are some in every frame then it can reduce the dimensions to the bounding box of the largest image. But for the most part I think exporting the entire stage is fine. |
|
Regarding "list of costumes" — yes! I agree. See my comments on Bernat's solution in the forum thread (I'm sorry to have "forked" the discussion across two sites!). Regarding parameters — I would say the only parameter worth exposing is the delay time. The rest of the options all have sane defaults that are very rarely modified in practice. Here is a proposed modification to Bernat's block: add snapshot of stage to [list] with delay (10) ms The list created would be a list of (costume, delay-time) pairs which you can feed to the "export GIF" block. For extra credit, the "10" number input could have a dropdown that lets you select "real time" as an option. It would infer the delay based on the wall-clock time since the last snapshot was added. Does this seem reasonable to you, Jens? |
|
Why such artificial delay, 10ms? As for single frames delay, it can be encoded in costume name eq. "frame1_x20" for waiting 20 x dt. Or as a property of JS costume object. |
As discussed here: https://forum.snap.berkeley.edu/t/snap-project-to-animated-gif/4895
(Don't worry! Not a "real" PR!) This is a proof-of-concept/discussion-starting Snap! library that uses gif.js to create GIF animations of whatever's happening on the stage.
Discussion topics:
Bugs: