Yes, the idea was to extend the libjpeg API with probably one new function that allows for setting the pixel format. If this function isn't called, then the default pixel format would remain the same as always (RGB), but the new function would allow it to be changed to BGR, RGBA, BGRA, ABGR, or ARGB, thus eliminating the need to perform those pixel conversions when using libjpeg.
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.) 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. Peter Åstrand wrote: > If I understand it correctly, the main problem is that the libjpeg API > isn't enough for these performance enhancements? In that case, would > it be possible to extend the API of "our" libjpeg, and then also write > compatibility stubs that emulates the extended API upon a "system > libjpeg"? > > I think that having a well-defined JPEG library API is important. For > example, people might eventually want to replace their normal libjpeg > library with our SIMD one. In that case it is of course important that > the API is compatible. It might also be useful to, for testing or > other purposes, replace our SIMD jpeg with something else, say a glue > to IPP or OpenMedialib. So having a well defined "border" seems very > useful to me. ------------------------------------------------------------------------------ _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
