On Tue, 31 Mar 2009 03:12:42 -0500 DRC <dcomman...@users.sourceforge.net> wrote:
> > 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? > That looks like a perfect way of solving it. The only gotcha is that JCS_RGB will have to mean "whatever the defines say" to stay compatible. Perhaps we need a JCS_REALLY_RGB or similar? We also need some define to allow people to ifdef any references to the new enums. > > 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. > Sounds like a good approach to me. Rgds -- Pierre Ossman OpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com
signature.asc
Description: PGP signature
------------------------------------------------------------------------------
_______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
