Kodi Community Forum
Up to 4x faster JPEG library - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Discussions (https://forum.kodi.tv/forumdisplay.php?fid=222)
+--- Forum: Feature Requests (https://forum.kodi.tv/forumdisplay.php?fid=9)
+--- Thread: Up to 4x faster JPEG library (/showthread.php?tid=96224)



Up to 4x faster JPEG library - plue - 2011-03-08

Could be interesting to change support of JPEG to this more efficient library?

With Intel Atom, using XBMC to show JPEG camera images take too long to change image.

libjpeg-turbo.virtualgl.org


- topfs2 - 2011-03-08

Thing is we don't generally deal with images directly (nor do we want to) but instead use a library which handles many different types. These libraries generally use the per type libraries (like this one) and I think this library is in fact using the same API as the traditional one. As such using these "turbo" libraries should be a simple matter of recompile our library with this library and recompile XBMC. There exist other optimized libraries like this for ARM etc which are magnitudes faster than the traditional one.

My point being that this is less of a XBMC thing and more of a distro thing which the builder and packager of XBMC needs to care for, so if your building yourself it should be rather possible to get this in by just doing some building of yourself and tell xbmc to link to a different libjpeg.

Would love to see how much difference it does on an ATOM, which is really slow with the traditional libraries.

Cheers,
Tobias


- ghostelement - 2011-03-08

I think someone should do a test compile with this included and see how much of a difference it makes. Then it could be decided if it should be used as a replacement. If this lib can be used on all platforms, it may be a good option.


- topfs2 - 2011-03-08

Well, we really want to move towards only using external libraries as that makes stuff like this simpler. If a platform benefits from using such a library then they build it using that one.

So while it may seem like the answer if its better to use that and provide it as an internal library its actually the opposite which is smarter (and more future proof and more portable) Smile


- ghostelement - 2011-03-08

I vote for future proofing! Smile