-
-
Notifications
You must be signed in to change notification settings - Fork 24k
[DRAFT] use libjpeg for improved jpg compatibility #104298
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
Conversation
|
I thought there’ll be more benefits to using jpeg turbo. How bad is it? |
|
Turbo compiles the same source files several times for different bit depths (8, 12, 16), puts the resulting object files into subdirs specific for that bit depth, before linking them all together. |
|
I think libturbo already has integration with thorvg. Those negatives about making the scons doesn’t seem that bad. |
The PCRE2 library does something similar to this, here's how we handle it in SCons: So something like this could possibly be done for libjpeg-turbo. If you want to explore it I'd suggest making it a separate PR so we can evaluate both implementations. In general I'm in favor of switching to a more complete and maintained library, but we need to make sure we strike the right balance in terms of added thirdparty code, complexity, and binary size. |
|
Declining, will go with libjpeg-turbo instead in #104347 |
Fixes #45523 #103951 #91600
Uses libjpeg from the Independent JPEG Group, which is pretty much the reference implementation. Might have been nice to use libjpeg-turbo instead for the speed improvements but it seemed too complicated to shoe-horn into Godot's scons system.
Doesn't appear to be any impact on speed or binary size as a result of the changes, but the images from those linked issues load correctly now.
Before I start on those I thought I'd see what you all think of the approach?