Continuous Integration with Travis

Travis is a continuous integration system which works nicely with GitHub, so while we've been using Buildbot since a long time and will continue to do it, we thought it could be nice to also try Travis and so now we have a minimal configuration file for it and it builds wxGTK after each commit.

You can check the latest Travis build status by just looking at this blog post: and you can click the button for more details. For the other ports and also to check if the tests pass (as Travis currently only checks the compilation and doesn't run the tests yet), see our Buildbot status page.

Help with pre-2.9.5 testing

We plan to release 2.9.5 next Monday, so any testing right now would be even more welcome than usual -- as 2.9.5 is supposed to be the last release before 3.0, it would be great to avoid having to do any big changes after it is done and for this we need to avoid having the kind of bugs requiring such changes in the release in the first place.

So if you can grab the latest sources from SVN or Git and test them with your application, it would be really helpful. Especially if you discover any news bugs while doing it. And even more so if you don't ;-)

Thanks in advance!

---

P.S. Currently wxX11 and wxMotif are known to be broken (and will be fixed before 2.9.5) so testing these ports is not worth doing, but all the rest of the ports are supposed to work.

The fastest image format to load is...

... surprisingly, at least to me, TIFF. I have recently added a simple benchmark for wxImage methods, mostly to be able to test the optimizations to wxImage::Scale() done by @Hsilgos, but it also looked like a good opportunity to test the speed of loading the same image in different formats. And it turns out that loading the image from TIFF is consistently faster than loading it from JPEG, BMP or PNG even though the JPEG file is much smaller and I'd expect this to play a role. Actually, either the TIFF library under Linux is particularly optimized or the other ones are not optimized at all because using the system libraries for all formats (except BMP which is always loaded using our own code), loading TIFF image is more than twice faster than loading the JPEG one, 8 times faster and 10 times faster than loading the PNG one. Under Windows, where our builds of the libraries, compiled without any particular optimizations, are used, TIFF is relatively twice slower as it's only 10% faster than JPEG, 4 times faster than BMP and 5 times faster than PNG but the differences are still quite big.

The fact that using libpng turns out to be slower (albeit not by a large margin) than our own naive BMP loading code is rather surprising too but perhaps it's due to the code in wxPNGHandler which tries to determine the alpha format in a not very clever way. It would be interesting to profile this further and also test with other images (currently I have a huge sample of 1) and at least determine whether TIFF is consistently faster or just for some images (and, if so, for which ones) and whether this is specific to the code in wxWidgets or if the TIFF protocol or library is just really more efficient.