On Sun, 29 Mar 2009 13:53:34 -0500 DRC <dcomman...@users.sourceforge.net> wrote:
> A thought just occurred to me. The performance enhancements I'm about > to make which eliminate buffer copies, pixel conversion, etc. depend on > the extensions to libjpeg that support compressing 32-bit pixel formats > directly from the framebuffer. Those aren't backward compatible with > the system libjpeg, and it would be difficult to make TigerVNC support > both paths. Thus, the performance enhancements might eliminate the > possibility of using the system libjpeg at all. How does everyone feel > about that? I really don't see any need to support using the system > libjpeg, because (theoretically, at least), anyone who can successfully > build our code can build our version of libjpeg as well. I think it > would be nice to support both paths, but not at the expense of performance. > My gut feeling is that we should keep compatibility with the standard libjpeg. Compile time compatibility is sufficient though (i.e. we can do two code paths with #ifdef:s). 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
