On Mon, 30 Mar 2009 13:40:22 -0500 DRC <dcomman...@users.sourceforge.net> wrote:
> > I proposed this originally, but let me propose it again -- why can't we > use the TurboJPEG API as our "border"? That's precisely what it was > designed for. That API is already implemented on top of mediaLib, IPP, > Quicktime, and libjpeg. It would be quite simple to implement two > versions of it in our code-- one to talk to a "system" libjpeg and one > to talk to our enhanced SIMD version. Then if we ever want to port to > Solaris, we simply drop in the mediaLib version of TurboJPEG, and it's > done. Users can also swap our libturbojpeg.so with the IPP-accelerated > version at run time if they want additional performance. It seems like > re-inventing the wheel to try and make the libjpeg API be our border, > because there aren't versions of that API implemented on mediaLib or > IPP, etc. (actually, Intel does have an IPP-accelerated version, but > it's not as fast as TurboJPEG.) > We still have the legal murkyness that got the discussion off track the last time. 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. 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. > Writing a compatibility stub using the existing libjpeg API starts to > get tricky, because the border becomes less well-defined. We'd > essentially have to perform color conversion outside of libjpeg and hand > it pre-converted YUV images. I'm not even sure how feasible or > performant that is. I'd much prefer to use an existing API like > TurboJPEG and perform color conversion internal to that API. > 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. 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
