Pierre Ossman wrote: > We still have the legal murkyness that got the discussion off track the > last time. > Well, I'm not married to the idea of using TurboJPEG. I was just throwing that out there as an idea. I do want to clarify, though, that the legal murkiness only exists when using the IPP version of TurboJPEG. The other versions are murk-free. TurboJPEG itself is a GPL-compatible library. The only thing that makes it murky is embedding the IPP code, but that's not what I was proposing to do here. I simply meant that we would give the user the option of using the IPP version at run time, and we wouldn't supply the murky version of the library with this project.
However, that's admittedly a weak argument for using TurboJPEG, because we intend to eliminate any dependence on IPP in the long run anyhow. > From a technical point of view, a properly designed abstraction layer > isn't a bad idea. But I still have hopes that an enhanced JPEG lib can > get traction outside of our project, and it has a better chance of > doing that if it remains compatible with the de facto standard API. > I don't think the ideas are necessarily contradictory. I agree that libjpeg/SIMD needs to remain as compatible as possible. However, what I was trying to figure out was how best to apply the performance enhancements while still allowing the user to build against the system libjpeg if they want. > What specifically needs to be added to get the libjpeg API feature > equivalent with TurboJPEG? Is it just the input/output color space? > That does not seem like a big obstacle. The code is more or less > already there, we just need to make sure it compiles all variants > instead of just one. > Yeah, that's pretty much it. And it occurred to me that an easier way to accomplish that rather than adding a new API function would be simply to extend the J_COLOR_SPACE enum to include JCS_BGR, JCS_BGRA, JCS_RGBA, JCS_ABGR, and JCS_ARGB. That way, we retain full ABI compatibility, and "old" libjpeg programs can use our version with no modifications, but "new" libjpeg programs that tried to use these enhanced colorspaces with an "old" libjpeg would get a JERR_BAD_IN_COLORSPACE error when calling jpeg_set_colorspace(). Do you foresee any problems with that approach? > Or we can let such stubs to what we do today, convert 32-bit RGB to > 24-bit RGB and let libjpeg handle the YUV conversion. We cannot get rid > of our conversion code as it is needed for the RFB protocol anyway. I > also have some ideas on cleaning it up and making it faster. > OK. Well, if it has to remain in the code base anyhow, I guess it's not that difficult to detect whether the libjpeg is enhanced or not and act accordingly. I guess that if you don't see any problem with extending the J_COLOR_SPACE enum as I propose above, then the best approach would be to make that extension to libjpeg/SIMD, then add either some logic or #ifdefs in librfb that bypass the 32-bit to 24-bit conversion routines if libjpeg/SIMD is being used. ------------------------------------------------------------------------------ _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
