[gif] - add gif support via giflib

[Memphiz]

This is a split off from #5166

This removes the old animatedgif impl. I was not able to test if this introduces regressions in any way. I just don't know how to trigger that old animatedgif code to verify that it still works.

We use giflib5 for depends and windows - but the implementation also supports the giflib4 api.

[notspiff]

thx...

[Memphiz]

Updated - @jmarshallnz , @t-nelson and @notspiff - the commits are suffixed with your nicks for better review.

Only unsure about the endianess @t-nelson - as i see @ace20022 copied the makro from here:

http://sourceforge.net/p/giflib/code/ci/master/tree/lib/dgif_lib.c#l27

so seems there is no be support inside the lib itself no?

[Memphiz]

Also the loopedonce bool was split into its own commit and moved to the other pr about animated splash ...

[Memphiz]

crap and with that m_Frames change it doesn't work anymore ... well thats it for some days from me ... nice weekend :)

[jmarshallnz]

Enjoy the sun - we've reviewed within the window, so all good once you get back to it to merge (i.e. no rush)

[Memphiz]

could you elaborate on the smart_ptr approach a bit - i guess you mean boost::shared_ptr <- std::vectorboost::shared_ptr doesn't change anything - i bet i didn't get the concept yet ;)

[jmarshallnz]

Yeah.

typedef boost::shared_ptr<GifFrame> FramePtr
std::vector<FramePtr> m_frames;

Then when you add a frame use:

FramePtr frame(new GifFrame(foo, bar));
frame->foo = bar;
m_frames.push_back(frame);

The copy constructor etc. can stay if you like (or alternatively make the definition, assignment etc. private so that no copy construction can be done?) but will be unused, as the vector will just be twiddling pointers when it resizes etc.

Basically it's just a nicer version of std::vector<GifFrame*> where you don't need to care about deletion when the vector goes away.

[Memphiz]

updated

[ace20022]

@Memphiz Can I help? The current situation is a bit confusing, what's the "head revision"?

[Memphiz]

@jmarshallnz updated - sorry i'm not really used to the boost stuff ;)
@ace20022 well i guess after the review is through i will squash this down to "your" 2 commits (the first 2 in this PR). After that i will rebase the animatedsplash PR ontop of that and we may start working on getting that right (same for your branch - you might want to rebase to mine as that gif implementation was reviewed and altered then which makes it "newer" then yours). Basically we just split it up in smaller peaces a bit ... divide and conquer ;)

[Memphiz]

@jmarshallnz one last thing - i didn't change the COLOR pointer as i don't feel comfortable with using a 4 char array there. It would break type safety and a ptr doesn't hurt imo.

[notspiff]

but obviously that did nothing for the peace of mind of ace. sorry couldnt resist ;)

[Memphiz]

wat?

[notspiff]

just a PIECE of bad humor

[jmarshallnz]

My version of the branch has fixes for COLOR, fixes the v4/v5 issue, and also some minor warnings fixes. Top 3 commits.

https://github.com/jmarshallnz/xbmc/tree/gifsupport3

Still need to check v5 build (doing so atm)

[jmarshallnz]

Top 5 commits should do it.

[Memphiz]

@jmarshallnz squashed it down (and your 5 commits into it aswell). Thats not meaning that i am not willing to do any more changes - i just wanted to get rid of the big commit count so that i don't have to do one big rebase at the end ...

[ace20022]

@Memphiz version built. While adapting the code, I've seen some other things I want to change. I'll try to do a pr against your branch tonight.

[Memphiz]

PRs done in the night always have some excitement - go on :D

[MartijnKaijser]

@Memphiz @fritsch is this obsolete when we wikll switch to ffmpeg?

[Memphiz]

I have no idea

[fritsch]

Nope - Gifs are handled separately, so this PR is not obsolete.

[fritsch]

@ace20022 can you also tell your 50 cents? :-) thanks much

[ace20022]

Superseded by #7960