GNOME Bugzilla – Bug 583767
gtk+ should optionally depend on medialib
Last modified: 2013-12-19 11:41:16 UTC
Current release of gtk+ has hard dependency on medialib which is imported when building. But medialib is a very large library (On my system, /usr/lib/libmlib.so.2 takes 21MB disk space and /usr/lib/libmlib/libmlib_sse2.so.2 takes 38MB disk space). In certain circumstances, such as for a live cd, we want to save as much disk space as possible, then we can include more softwares on the cd. So I suggest making gtk+ optionally depend on medialib by using dlopen to load the library if it's installed. Making gtk+ optionally depend on medialib can also reduce the memory usage of the system on live cd. Please refer to bug 344813 and 442888 for the old patch integrating medialib into gtk+.
Created attachment 135296 [details] [review] Patch to fix the problem. Use dlopen &dlsym to load medialib.
Created attachment 135297 [details] test result with medialib support before applying my patch. Test result with medialib support before applying my patch.
Created attachment 135298 [details] test result with medialib support after applying my patch. Test result with medialib support after applying my patch.
Comment on attachment 135296 [details] [review] Patch to fix the problem. I also fixed a few performance problem in the current medialib support of gtk+.
I suggest you provide the performance improvements separately. It's otherwise impossible to refer to and compare specific changes in behaviour at any later point in time.
Created attachment 135359 [details] [review] This is the 1st patch with no performance improvement. This patch uses dlopen & dlsym to load medialib and replace all direct function calls with calls to the function pointer. I will attach performance later.
Yes, I agree the performance improvements should be filed as a separate bug, since they are independent of this change. We discovered that mediaLib is slower when using PIXOPS_INTERP_NEAREST interpolation. It is much faster when using any other interpolation type, though. So the main "performance improvement" was removing the mediaLib integration for that interpolation type. This also simplified the code a bit since it allowed the if-tests to be reworked a bit to be more efficient since this case no longer needed to be handled by the medliaLib code. Wang, when you file the other bug report, could you attach timescale test program output showing that PIXOPS_INTERP_NEAREST is faster without mediaLib?
So, I am pretty strongly against any dlopen hacks. Having a --disable-medialib configure option is something I would consider.
A --disable-medialib configuration option would not meet our needs. The reason behind making this change is because the mediaLib libraries are large, and if it could be made an optional dependency, then Sun could avoid shipping mediaLib on LiveCD. However, when users download and install mediaLib, they should get a performance boost. So, the advantage of using dlopen is that it allows GTK+ to be shipped without mediaLib support, but mediaLib will be used if it is present on the system. We could maintain this as a patch in our build systems, but it would be nice to get the code upstream if possible.
Having a --disable-medialib also means we have to provide two builds of GTK+. One for those who need medialib support. Another for those who do not. But actually we want to achieve is: 1) only 1 build to meet all users' needs. 2) medialib support can be disabled if it's not need. And if the support is disabled, GTK+ should not link to libmlib. So we do not have to load the library into memory or ship it in the LiveCD.
I'm not convinced. The same argument could be made for every library that GTK+ links against... Maybe you should just keep the dlopen part in your package.
Yes, the same argument could be made for every library that GTK+ links against. But I think none of them is as large as medialib (neary 60MB). So I really hope that the patch can be committed into the repository.
*** This bug has been marked as a duplicate of bug 585220 ***