Hi, sometime ago I got a nice piece of code from here, but I am not able to find the thread anymore......it's a library free gif decoder which works quite fast. I wanted to tune it a little bit, but for now I could not speed it up significantly.

Using gif images and this decoder inside a code means the following adantages: a small exe file because no lib is needed and quick decoding!Anyway, if some additional tuning could be done in the code, I would be happy!

Even I do not know the original author (there are to few assembler lines to say it's from wilbert ), I'll post it here - hopefully the maker of the code has no problems with that.

Thanks for your replies, I must have missed netmaestros masterpeace and did not find wilbert's thread as well (never search for "Gif Decoder" in this forum if you want to find a "GifDecoder" )

I will check for differences to wilbert's updated code and try to find a possibility to speed it up (maybe by using some global variables). Every millisecond counts - I am use this routine thousands of time in a program to "expand" an image in memory, grab a small part of it and free it immediately, therefore my programm only needs a small amount of memory in general.

(never search for "Gif Decoder" in this forum if you want to find a "GifDecoder" )

phpBB's Search really sucks unfortunately it's still good for some things, searching by Author for example, but 99% of the time i just use google with inurl:purebasic (which also is handy in finding code from the German/French/Russian etc forums, and sometimes they were the only place i found a solution!):https://www.google.com/search?q=gif+dec ... Apurebasic

_________________Thankyou to all the coders who generously helped & encouraged me in the nearly 2yrs when i was welcome here,it was a tremendous privilege. I learned a lot. I wish you and your families all the best and success for the future.

Meantime I stripped off some "unneeded" things (because my image won't have transparency, interlace mode etc.), but this saves just few milliseconds. There are two procedures which are responsible for around 60% of the complete calculation time, GifCopyPattern (~35%) and GifCopySwapRB (~25%). I fear, there's no chance to speed this up

I compressed the image (and the result was 8% smaller than the original gif file), included it and decompressed it - everything works fine, the compressing takes a while but this wouldn't be done in the program, so decompressing is the main point: and, it is more than 20% slower than Wilbert's gif decompressor.

LZMA is very slow though, thats the price you pay for its excellent compression ratio; maybe Zip is better for this?

_________________Thankyou to all the coders who generously helped & encouraged me in the nearly 2yrs when i was welcome here,it was a tremendous privilege. I learned a lot. I wish you and your families all the best and success for the future.

LZMA is very slow though, thats the price you pay for its excellent compression ratio; maybe Zip is better for this?

Tried zip first, but the resulting size was "horrible" - 30% larger than the original gif file. On the other hand, it would uncompress around 10 to 15% quicker than doing gif decoding. So it could be an alternative, but hopefully even more optimization can be done

Some updated information as the newest PureBasic version includes a GIF Decoder

- the PureBasic's internal GIF decoder has a small footprint (exe grows only by around 10K) but is relatively slow (around twice the time of Wilbert's solution)- I've removed some features from Wilbert's original code (now it will work only for non interlaced single images using a palettes)- I've also eliminated the Start/StopDrawing commands (faster and smaller exe)- I don't believe a lot of tuning can be done (except there's another trick to speed up the GifCopyPattern routine, which needs most of the calculation time)