FYI-- you can read more here: https://github.com/libjpeg-turbo/libjpeg-turbo/pull/27
but I'm convinced that this is something that needs to be addressed within TigerVNC, not within libjpeg-turbo. TigerVNC is using its own custom destination manager for the libjpeg API, which is why this only affects their server and not the TurboVNC Server or other VNC implementations that use libjpeg-turbo. The issue is definitely server-side-- i.e. the server is generating a bad JPEG image. Unknown why the TigerVNC Viewer is unaffected, but probably it's because that viewer can't select JPEG quality 95. The issue seems to relate to the size of the generated JPEG image, which is a function of both the source image and the JPEG quality. Pierre proposed a patch to libjpeg-turbo that does work around the issue, but it changes the behavior of the libjpeg API in a way that it is incompatible with libjpeg, so I am disinclined to accept that patch. I have verified that this issue also exists when TigerVNC is built with libjpeg. I don't doubt that this issue stems from a "quirk" in libjpeg, but the fact of the matter is that the quirks in the libjpeg API are now somewhat canonical, since that API has been virtually unchanged since 1998. libjpeg v8 introduced in-memory source/destination managers as a way of making it easier for applications such as TigerVNC to do compression to/decompression from memory buffers without having to deal with these canonical quirks. On a side note, I'm curious as to why you can't use the TurboVNC Server. We are fastly approaching feature parity with the TigerVNC Server. Our latest builds have TLS encryption support, so really the only major feature we're now missing is Xinerama support (which is forthcoming-- probably will be in TurboVNC 2.1.) On 10/13/15 6:00 PM, Brett Williams wrote: > Bug filed: > > https://github.com/TigerVNC/tigervnc/issues/218 > > I am not sure how much context to include. > > On Tue, Oct 13, 2015 at 4:32 PM, Brian Hinz > <[email protected] <mailto:[email protected]>> wrote: > > Would you mind filing a bug report on the TigerVNC github tracker so > that we can follow up on it there? And since that image looks like > an ASIC layout, can you tell me what application triggers it so I > can try to reproduce (you can email me off list if you want). > > Thanks, > -brian > > On Tue, Oct 13, 2015 at 6:20 PM, Brett Williams wrote: > > I've been unable to reproduce the problem using the TurboVNC server. > > On Tue, Oct 13, 2015 at 3:05 PM, DRC wrote: > > OK, well the image is definitely corrupt, meaning that this > is a server-side issue. Is there any way you can try to > reproduce the issue using the TurboVNC 2.0 server? Building > the TigerVNC Server isn't exactly straightforward, so in > order for me to send you an instrumented binary with the > afore-mentioned codec checks, I'm going to have to do that > using our server code. > > It may also be that there is simply a rare bug in the > TigerVNC encoder that doesn't affect the TurboVNC Server. > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > TurboVNC-Users mailing list > [email protected] > <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/turbovnc-users > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > TurboVNC-Users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/turbovnc-users > ------------------------------------------------------------------------------ _______________________________________________ TurboVNC-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/turbovnc-users
