[epiar-devel] Threads, Networking, etc..

Tue Dec 22 00:42:51 PST 2009

I don't aim to confuse when I complain of third-party library bloat. This, however, should not be confused with a dislike of third-party libraries, nor should it be assumed that the decisions made about libraries with long-standing use should be questioned. Here's the breakdown:

zlib, libpng, SDL, SDL_image, libxml2: incredibly acceptable. They've been in Linux repos since the late 90s or before. They're very, very stable, well-known, well-documented, and work well on all major platforms.

Lua: again, fine. It's coded using ANSI/ISO C so it's relatively portable and we include it in our tree, so it's our problem anyway. Not a "third party" library in the sense of our concern: bloat (requiring pre-reqs).

freetype2/ftgl: Matt probably should maintain his freetype/ftgl branch (or we should all maintain it) just in case these performance issues crop up again. afont, until Matt's buggy OGL driver, was a great choice, written by a very competent programmer. Font support in four short-ish files that even pre-builds the glyphs into lists? I'm a little surprised this even came up. Since the Font class is basically done, the only problem with keeping both around is that we don't want to maintain .ttf and .af files. I don't expect Matt to debug afont's OGL issues, but should anybody want to give him a new computer, I'd approve (and hope his issues don't crop up with anybody else). -- Also Matt, do you use Snow Leopard?

physicsfs: I never liked this. It should go. The path independence is nice, the archive reading support is unnecessary (we've already done it ourselves with .tgz files), and the rest makes me feel like we're killing ants with hammers, or some other clever metaphor.

On Dec 21, 2009, at 7:42 AM, Maoserr wrote:

> I think we need to have a discussion on what the problem is with our third  
> party library usage and what needs to be done about it. I'd rather get  
> this out of the way instead of having code in limbo all the time.
> 
> Libraries we're using (and what other options we have),  these are sorted  
> by how much trouble I think it's going to take to replace:
> ZLIB -> I don't see how we can eliminate this and still use PNGs
> Libpng -> I don't see how we can eliminate this
> Lua -> I don't see how we can eliminate this (I've already tried LuaJIT,  
> doesn't help much in terms of performance on first attempt)
> SDL -> 1) can be eliminated with pure OpenGL code - not a good idea. 2)  
> Other libraries? SFML? Allegro?
> SDL_image -> also can be eliminated with pure OpenGL. 2) other ideas?  
> SOIL, glpng?
> libxml2 -> This is bloated if we're just going to read and write xml.  
> other ideas, roll our own parser, use smaller libraries like TinyXML  
> (original, xpath, or ++)
> freetype2 -> Can be eliminated, but then won't be able to read ttf files
> ftgl -> Same as freetype2 (we can extract only the code we need from this  
> and rewrite it to fit our needs better, it'll still be easier than writing  
> from scratch)
> physicsfs -> I don't see a need for it, and since this has been in limbo  
> for so long, I vote we get rid of it completely.
> 
> am I missing anything?
> 
> Right now, I think it's a good idea to get people thinking about this, so  
> we can sooner or later merge onto a universal branch with libraries we can  
> all agree to work with.
> 
> On Sun, 20 Dec 2009 21:42:51 -0500, Chris Thielen <cthielen at mac.com> wrote:
> 
>> Agreed! I've already lamented about our third party library bloat, but  
>> we should absolutely use SDL's included threading facilities for  
>> whatever's necessary. Note that things like SDL audio already use  
>> threading without letting you know, so we shouldn't introduce threading  
>> where not necessary.
>> 
>> SDL_net is also a really good decision. The SDL libraries may not add  
>> features often, but they're incredibly well tested across many platforms.
>> 
>> On Dec 20, 2009, at 6:05 PM, Chris Walton wrote:
>> 
>>> I've not used ACE, but I've researched it. It's quite heavyweight and
>>> seems grossly overdone for Epiar.
>>> 
>>> commonc++ I've never heard of.
>>> 
>>> Boost isn't a bad choice, plus it provides a bunch of other neat
>>> things (though you have to be careful, some boost constructs are
>>> super-slow despite being extremely well programmed).
>>> 
>>> However, SDL already provides all those platform-independent things.
>>> Network support is provided by SDLNet, which is also programmed by Sam
>>> Lantinga. While I haven't worked with SDLNet, knowing that it's
>>> created by him pretty much tells me that it's of extremely high
>>> quality. Sam Lantinga is, among other things, the creator of SDL and
>>> lead programmer at Blizzard, and a coder that I respect very, very
>>> much. :)
>>> 
>>> -- Chris
>>> 
>>> On Mon, Dec 21, 2009 at 1:44 AM, Shawn Reynolds <eb0s at yahoo.com> wrote:
> <snip>
>>> 
>>> _______________________________________________
>>> epiar-devel mailing list
>>> epiar-devel at epiar.net
>>> http://epiar.net/mailman/listinfo/epiar-devel
>> 
>> _______________________________________________
>> epiar-devel mailing list
>> epiar-devel at epiar.net
>> http://epiar.net/mailman/listinfo/epiar-devel
> 
> 
> _______________________________________________
> epiar-devel mailing list
> epiar-devel at epiar.net
> http://epiar.net/mailman/listinfo/epiar-devel