GiF playing very slow Help!

[adamkatz2003]

Hi in my app i have a 31 freames gif and it weighs 3 Megabytes,
When the gif is playng livecode is slowing down a lot
But the real problem is that on my android phone it is running
Even slower,
Is there anything to do?

[stam]

You may find this link helpful: viewtopic.php?t=11982

Can you post the code you're using to play the animated GIF?
If it's a particularly problematic GIF, it may be worth sharing that for testing as well, if that were possible (at 3 Mb, you'd need to share a link to it, rather than post direct in forums).

Would make it a lot easier for people to recommend optimisations.

Regards
Stam

[adamkatz2003]

I have no code in the gif element

[stam]

Is it slowing down when you're doing something else?
You may have issues if running a loop for example - if that's the case you probably want to give some time to the engine to do it's housekeeping (eg animate the GIF) by adding this to the loop:

Code: Select all

wait 1 millisecond with messages

If there's no code running and it's still abysmally slow on android, that may be an issue of size (3 Mb is quite big for an animated GIF) and it's likely with the smaller screen of android devices you can just reduce the resolution/size of the image so that it takes up much less RAM.

Failing that, it may be an bug on android i guess.

[Klaus]

I heard in the past that animated GIF files are quite RAM hungry, so maybe this is the case here, too!?
I would turn the GIf into a movie format (MP4) and display that instead.

[richmond62]

Chop the GIF up into its constituent frames: you can
probably reduce them to less than 3 MB, then animate
them another way.

[jacque]

There are two ways to create a gif file. One way saves the entire content of every frame, the other way is to save only the differences between frames. It's been too long since I created any gifs so I don't recall what they call those formats, but the second method can reduce the size dramatically. A 3MB gif is very large and it's probably using most available RAM. Swapping frames may mean it has to use disk space as temporary memory and that will cause slower animation.

Or do as Klaus says and make it a movie.

[PaulDaMacMan]

There are two ways to create a gif file. One way saves the entire content of every frame, the other way is to save only the differences between frames. It's been too long since I created any gifs so I don't recall what they call those formats, but the second method can reduce the size dramatically. A 3MB gif is very large and it's probably using most available RAM. Swapping frames may mean it has to use disk space as temporary memory and that will cause slower animation.

Or do as Klaus says and make it a movie.

I know this thread is a little dusty, but has no one really ever written an xTalk library for doing stuff with GIF frames / files? I mean I've written scripts that parse GIFf headers for basic info (H/W Size in px, frameCount, Color Index, etc.) like 27-28 years ago (needed an XCMD to read binary / null bytes to do stuff like that in HyperCard back then). I re-wrote it, adding jPEG and PNG header parsing using LC script a few years back. I'll have to dig that out and see if I can't add some stuff like individual frame extracting. These file formats have been around for a long time and are well documented.

If there was a way. it could be useful to load the frames image data into memory, like in an array for fast access. I've experimented with that technique with 'compiled' SVG' image data in LC and it's pretty darn fast to render, might work just as well with bitmapped image frames. And the image data could be passed around in memory for other uses ( like applying filter effects with CoreImage Filters for example )

I've only ever used GIF for short animations like an animated loading graphic, not sure what the goal of the OP GIF was, but a 3mb GIF is rather large for a GIF file. getting into movie territory and with todays computers and devices you'd probably be better off using a compressed video format like .mp4.

[FourthWorld]

FWIW Ken Ray did some extensive scripting to generate activated GIFs for his Stykz app. He may be in a position to help.
http://www.stykz.net

[richmond62]

Brainless search on internet:

https://ezgif.com/optimize

https://www.iloveimg.com/compress-image/compress-gif

https://www.xconvert.com/compress-gif

and so on, and so forth . . .

[PaulDaMacMan]

I know there's a few JavaScript libraries (or web ports of common offline libraries) that can do those sort of thing, but we may have our GIF's image data embedded into our stacks inside 'the text of image..." (that always bothered me, it is NOT text ,it's bin data from one of several supported file formats) which we can easily get and set. I suppose you could pass the GIF data in to a BrowserWidget running one of those JS libs on it, but that seems rather convoluted.
https://en.wikipedia.org/wiki/GIF#Image_decoding
Wouldn't need to decode every LZW compressed Index color pixel just to extract an individual image frame, just copy and/or modify the header stuff and then combine it with the parsed out color tables / image data from the frame you want to extract and put it into a new GIF container.
Although, as already mentioned, there's a format where only the changed areas of pixels from one frame to the next are actually stored, so that could be more difficult to parse.

Then again why reinvent the wheel when you could use Extension Builder to wrap one of the many existing libraries such as giflib (libgif) which is already present in just about everything online related in the last 30+ years (I mean it's a CompuServe format!), most OSes probably have it preinstalled somewhere. I'm also fairly sure it's the very same C code that LiveCode has used to do GIF stuff so that might only require a 'binds to "<builtin>"" binding string.

On the macOS I'm certain you can use NSImage / NSBitmappedRep to extract and combine the individual image data to/from GIF format (IIRC I've seen AppleScriptObjC script that did it), but I would want something more cross-platform like ImageMagick for general use (alternatively, I guess someone could wrap all of GNUStep's libraries LOL), but I'm sure it could be done with plain old LC-Script as well (using binaryEncode/binaryDecode).

[PaulDaMacMan]

Duh... K.I.S.S.!
For extraction of frames from script you can simply 'export snapshot of <control>' to <bitmapFormat>' ( GIF or PBM which is basically a plain RGBA bitmap) in conjunction with a repeat loop that's iterating frames in an image control with the GIF (with a 'G' as in Garaphics ) in it. The script could maybe even create [script only] [invisible] stack [stackName [with background]] with an 'invisible image' or in-memory-only 'template image' for faster offscreen rendering?

Combining single GIFs into a newly animated GIF bitmaps sequence is another matter, but I can't imagine it's all that difficult to write out your basic uncompressed animated-sequence in GIF89a (IIRC the 1987 version didn't have animate options). I may put some time into this as I want to be able to script-making GIFs because that's fun!

EZGIF website has nice inter-frame blending options though:

ezgif-4-e58d5d1614.gif (64.19 KiB) Viewed 21677 times

[richmond62]

Well, I have been using images as a backGroundPattern of a graphic rectangle for years when getting kids to make side-scrolling games. I usually export the frames from animated GIFs with GIMP.

This, generally results in a collection of frames that, together, take up a lot more space than the GIF they are derived from.

So, using a GIF optimiser for an application on a mobile device, where file size is very important, would seem more sensible.

[PaulDaMacMan]

Well, I have been using images as a backGroundPattern of a graphic rectangle for years when getting kids to make side-scrolling games. I usually export the frames from animated GIFs with GIMP.

This, generally results in a collection of frames that, together, take up a lot more space than the GIF they are derived from.

So, using a GIF optimiser for an application on a mobile device, where file size is very important, would seem more sensible.

That's probably creating a bunch of redundant pixel data (as mentioned there is format support for more efficient methods) or duplicating color indexes, and/or is using non-LZW-compresssed bitmaps (which LZW no longer has the paten issues of yesteryears). Ideally we would want to use a library that can produce efficient/optimized animated-GIF from a collection of individual frames.

Back in the early to mid-1990s I used some freeware utility (I wish I could remember the name) that somehow made GIFs that were significantly smaller than the smallest file size I could ever produce with any of the commercial softwares that were around at the time, like a 10kb GIF would output a 2kb GIF with the same pixel dimensions and similar visual quality. It was quite remarkable and useful at a time when residential internet speed was 56Kbps or less.

[JereMiami]

Step 1: Go here https://www.xconvert.com/compress-gif

Step 2: Try reducing pixels

Step 3: Import image into livecode

Still slow?

Step 4: Try reducing pixels and frames in Step 2, repeat Steps 1-3

Still slow?

Step 5: Try reducing pixels, frames, and quality in Step 2, repeat Steps 1-3