Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use libjpeg-turbo, use common libs with crengine #243

Merged
merged 8 commits into from
Oct 22, 2014
Merged

Conversation

hwhw
Copy link
Member

@hwhw hwhw commented Oct 21, 2014

Switch libjpeg to libjpeg-turbo: This will give a slight performance
advantage. Also, it will offer us the Turbo-JPEG API, which is a much
simpler approach to render JPEG/JFIF data. This is without
setjmp/longjmp exceptions and will allow for an easy FFI-based pic_jpeg
interface.

Also fix dependencies of our CREngine integration to use the common
build of Freetype, libpng and jpeg (using libjpeg-turbo). This will
mainly make the resulting library smaller, and remove redundant code.

Needs koreader/crengine#3

Switch libjpeg to libjpeg-turbo: This will give a slight performance
advantage. Also, it will offer us the Turbo-JPEG API, which is a much
simpler approach to render JPEG/JFIF data. This is without
setjmp/longjmp exceptions and will allow for an easy FFI-based pic_jpeg
interface.

Also fix dependencies of our CREngine integration to use the common
build of Freetype, libpng and jpeg (using libjpeg-turbo). This will
mainly make the resulting library smaller, and remove redundant code.
@hwhw
Copy link
Member Author

hwhw commented Oct 21, 2014

Note: This will require nasm on build-time. We could get rid when we use --disable-simd with configure, and it is relevant only on x86/x86_64. Please discuss.

@hwhw
Copy link
Member Author

hwhw commented Oct 21, 2014

Note: This probably needs more testing before using it.

@NiLuJe
Copy link
Member

NiLuJe commented Oct 21, 2014

IIRC, jpeg-turbo also provides neon assembly routines, so the nasm comment would also apply for the Kindle/Kobo builds ;).

I'm actually not sure why this has worked before. The error crept up
the first time for me here.
@hwhw
Copy link
Member Author

hwhw commented Oct 21, 2014

PNG rendering via CREngine seems to be broken. Not sure yet why that is, will investigate. Freetype and JPEG seem to work just fine.

use our own zlib build with CREngine (needed when the sysroot/system
does not provide a zlib - also this will use a known version)
@chrox
Copy link
Member

chrox commented Oct 22, 2014

UPDATE:
It should be fixed with hwhw#4.

chrox and others added 5 commits October 22, 2014 13:23
And also revert the lazily load pthread.
It seems that luajit cannot resolve symbols recursively from dynamically linked
libraries like in the linux. So that we do need to get platform specific pthread
libraries in different platforms. So does the mupdf library.
chrox added a commit that referenced this pull request Oct 22, 2014
use libjpeg-turbo, use common libs with crengine
@chrox chrox merged commit 3ff07f9 into koreader:master Oct 22, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants