DRC,

My main reason for using TigerVNC server is that is what is installed, and
the deployment I'm going to be testing for shortly does not have the
TurboVNC server installed.  I won't have root access at that point, so in
order to get TurboVNC server installed I'll have to make a case for them
doing it for me.

I'll work the next couple of days with the TurboVNC server and report back
(I've still got a machine I can do it on).

On Sat, Oct 17, 2015 at 12:09 PM, DRC <[email protected]>
wrote:

> 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
>
------------------------------------------------------------------------------
_______________________________________________
TurboVNC-Users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/turbovnc-users

Reply via email to