Adam Tkac wrote:
> On Mon, Apr 06, 2009 at 10:06:45AM +0100, Tim Waugh wrote:
>
>> On 04/04/2009 08:58 PM, Kevin Kofler wrote:
>>
>>> Rawhide Report wrote:
>>>
>>>> tigervnc-0.0.90-0.3.1.20090403svn3751.fc11
>>>> ------------------------------------------
>>>> * Fri Apr 03 2009 Adam Tkac<atkac redhat com>
>>>> 0.0.90-0.4.20090403svn3751
>>>>
>>> [snip]
>>>
>>>> - use built-in libjpeg (SSE2/MMX accelerated encoding on x86 platform)
>>>>
>>> Shouldn't this be added to the system libjpeg instead, so all programs
>>> benefit?
>>>
>> Not only that but security updates for JPEG implementation flaws will
>> require vnc updates as well.
>>
>
> Right you are, get that improvements to upstream will be the best
> solution. Unfortunately no upstream for libjpeg is active so we can't
> share TigerVNC code easily.
>
> There were no security issue in libjpeg for ten years (please fix me
> if I'm incorrect) so I don't think that vnc will suffer due builtin
> jpeg. As written on
>
http://www.mail-archive.com/tigervnc-devel@lists.sourceforge.net/msg00225...
> TigerVNC consumes approximately 40% less CPU when it uses builtin jpeg
> so it is a valid reason, I think.
>
> Adam
>
>
Actually, upstream of libjpeg *is* active, he's just not communicating
that fact. I made an attempt to re-ignite activity there and get
several common patches applied, and had buy-in from Tom Lane, the RH
libjpeg maintainer, and the majority of the
SF.net libjpeg project team.
Guido Vollbeding is apparently working on a new release, but isn't being
particularly communicative or transparent about it. If you want to
review or join the discussion, see the
SF.net libjpeg list.
Thanks for info. I'm going to discuss future of TigerVNC enhancements
there.
Adam
--
Adam Tkac, Red Hat, Inc.