#25 Options and functionality to animate GIFs; Comix 4.0.4

open
nobody
None
5
2009-06-25
2009-06-25
No

Here's my last patch for today. I gotta go eat.
This adds a preference to animate gifs, off by default, as well as a command line argument. If you have it off by default and don't use the command line argument on a book that starts with an animated gif, that gif won't animate until you reload by going to a different archive, even after you turn on the preference. There are a lot of problems with the PIL handling of animated images, so the biggest problem is that GIF images won't be subject to resize, enhance, flips, rotations, etc. Non-animated GIF files will still do things like normal.

I'm also attaching combo-patches for the other two revisions I put up today. The names should be somewhat self explanatory, and the descriptions are on those pages.

Discussion

  • Alan Horkan
    Alan Horkan
    2011-04-24

    First off nice work adding animations to Comix.

    I've a few questions, it would be really great if I get a response but it has been such a long time since the patch was filed I wont take it personally if there's no reply.

    I took a quick look at the patches.

    I don't see anything about Slideshow mode (admittedly I only skimmed the code). The time needed by an animation could be more than the delay on the slideshow. Probably best not to overcomplicate it. I suppose trying to work around this is too messy and users will have to figure this out and use a longer delay in the slideshow mode. Any thoughts on this?

    Shouldn' the feature be on by default? Or always on to keep things simpler?
    I think there is a risk users will never discover a feature that is off by default and requires a command line argument or preference to turn it on.
    (Turing it on by default would also mask the mentioned bug that the perference does not instantly apply.)

    For reference: Netscape/Mozilla had a preference for animated images,
    animate:
    number of times as specified; (Animation is on by default)
    once;
    never

    Infinitely looping animations can be annoying but a setting to animate once work well. If an animation last long enough for users to actually see it is there they can hit refresh to see it again, similarly user could move back one page and forward again to force the an animation to replay.
    Turning animations on always would be even simpler.

    Although the option is only implemented for GIFs it could in theory at least apply to other image formats (MNG, JNG, others possibly). The user interface labels should not probably not specifically mention GIF, see Netscape/Mozilla for reference purposes.

    Command line arguments too are best if they are simple and generic and memorable so I would recommend "--animate" instead of "--animate-gifs"
    At the risk of repeating myself (shouldn't this be on by default and) do users need the command line argument to turn it on?
    The command line argument seems like it might be useful for developers and testers but not really something readers would know/remember at startup and want to turn on just this once (as opposed to say manga mode, which you could know from the title of a comic and want to turn on temporarily).

    Thanks again for the good work, I'm glad to have it included.

    If anyone wants an easy way to try this out I see HoverHell has already included this patch in his branch/fork/spoon of Comix
    https://github.com/HoverHell/Comix
    (it is not yet included in MComix)

     
  • I'm sure there wasn't anything about slideshow mode. I'm not sure how tough it would be to determine the length of the animation when it's loaded, but that would be a good addition for slideshow mode. Extra animation options sound good, too, though when I was doing patches, the options menu was becoming a little cluttered with things.

    I believe the reason I had it off by default was because it took significantly more time to load an image, since it had to do a load and determine if it was animated, then load it standard if it wasn't. Something like that, anyway. There's probably a much better way to do it with a different image library or a wrapper or something. There was or should have been an option in the options menu somewhere to turn it on, which I believe would persist between instances. The command line argument could be easily simplified, and it was there for when I knew I'd be opening something with animations in it ahead of time.

    I've never seen those other formats anywhere, but it's good to know there are gif replacements out there. I don't know if comix even supports those formats by default, though. I sort of remember a extension-based filter when extracting the images, though I could easily be thinking of something else.

    I'll have to check out the other builds sometime. Let me know if I missed addressing anything.

     
  • Alan Horkan
    Alan Horkan
    2011-04-25

    If there's significant performance hit then the command line argument seems like a necessary evil, but that it would be removed if the peformance issues could be avoided, thanks for explaining.

    GdkPixbufAnimation might be another way to approach it
    http://www.gtk.org/api/2.6/gdk-pixbuf/gdk-pixbuf-animation.html
    I guess it will have it's own downsides and tradeoffs too.
    I've yet to see a Comic archive that wasn't JPEG or PNG, it will probably be pretty rare that I would need GIF support
    ;)
    http://www.explosm.net/comics/1007/

    It is amazing how GIF has survived. Most of not all the patents have expired by now so GIF will stay with us as a legacy format. Tricks with javascript, Flash, or Video have largely replaced GIF anyhow. (I'm surprised MNG/JNG never caught on but most people have no need for animated or layered images, and PSD remains the de facto standard.)

    I might make a few minor tweaks to the patch and see if I can get the MComix developers to include it in their fork too.

    Again thanks for your patch, and thanks taking the time to answer my questions.