Sure. The decompress function inside rdr/ZlibInStream.java uses a byte
array with a default size of 16K as the output for the inflater, as does the
C version. Since the C-version sets avail_out in the ZStream, zlib knows
how much space is available in the ouput buffer and doesn't inflate more
data than the buffer can hold. The native java inflater has no equivalent,
so a call to inflate can produce enough output data to exceed the buffer
size. I could arbitrarily increase the buffer size, but this is wasteful
and bound to break depending on desktop size and compression ratio. I could
also allocate a buffer large enough by passing the
fbWidth*fbHeight*bytesPerPixel to the ZlibInStream constructor, but for a
large enough desktop (keep in mind that the Tight encoder allocates 4
streams) this can require enough memory to exceed the default initial heap
size of the Java VM. I haven't seen just how large of a desktop I can run
before the old java client breaks, but passing 3840x1140@24bpp to the
constructor is enough to run out the initial heap in the new one.
Also, using JZlib adds a degree of symmetry between the java and C versions,
which I see as a bonus from a maintenance standpoint.
-brian
On Thu, Jun 16, 2011 at 3:30 PM, DRC <dcomman...@users.sourceforge.net>wrote:
> 3-clause BSD is GPL-compatible, so legally there is no problem, but can
> you explain further the technical justification?
>
>
> On 6/16/11 2:13 PM, Brian Hinz wrote:
> > Assuming that it's OK legally, would anyone object if I were to import a
> > copy of JZlib (http://www.jcraft.com/jzlib/) into the TigerVNC java
> > client's tree and revamp ZlibInStream so that it's consistent with the C
> > version? JZlib is released under a BSD-style license
> > (http://www.jcraft.com/jzlib/LICENSE.txt):
> >
> > JZlib 0.0.* were released under the GNU LGPL license. Later, we have
> switched
> > over to a BSD-style license.
> >
> >
> ------------------------------------------------------------------------------
> > Copyright (c) 2000,2001,2002,2003,2004 ymnk, JCraft,Inc. All rights
> reserved.
> >
> > Redistribution and use in source and binary forms, with or without
> > modification, are permitted provided that the following conditions are
> met:
> >
> > 1. Redistributions of source code must retain the above copyright
> notice,
> > this list of conditions and the following disclaimer.
> >
> > 2. Redistributions in binary form must reproduce the above copyright
> > notice, this list of conditions and the following disclaimer in
> > the documentation and/or other materials provided with the
> distribution.
> >
> > 3. The names of the authors may not be used to endorse or promote
> products
> > derived from this software without specific prior written
> permission.
> >
> > THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
> WARRANTIES,
> > INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
> AND
> > FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
> JCRAFT,
> > INC. OR ANY CONTRIBUTORS TO THIS SOFTWARE BE LIABLE FOR ANY DIRECT,
> INDIRECT,
> > INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> NOT
> > LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> DATA,
> > OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
> > LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
> > NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> SOFTWARE,
> > EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> >
> >
> ------------------------------------------------------------------------------
> >
> > This appears to be consistent with the list of GPL-compatible free
> software licenses listed on gnu.org <http://gnu.org>. Also, the JZlib
> home page notes that JZlib is used in JmakeTxt, which is released under the
> GPLv2. I can contact JCraft to get confirmation.
> >
> > The reason that I ask is that since adding support for Tight encoding,
> I've periodically encountered an exception thrown by the call to
> java.util.zip.Inflater.inflate in ZlibInStream. This because the output
> buffer for the decompression is a fixed size, and the native java Infalter
> class does not provide a means to handle compressed data whose uncompressed
> size is unknown prior to decompression. In the C version, zlib handles this
> via avail_out, and in the previous java client the decompression buffer is
> allocated based on the required size. The problem with just allocating
> bigger decompression buffers is that for large desktops, this can cause the
> Java VM to exceed the initial heap size.
> >
> > When implemented with JZlib, the heap size limitation does not seem to be
> an issue, and as far as I can tell, the performance is no worse (possibly
> even better). The size of the resulting jar file only increases by ~30k
> when all of the JZlib classes are included.
> >
> > Thanks,
> >
> > -brian
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > EditLive Enterprise is the world's most technically advanced content
> > authoring tool. Experience the power of Track Changes, Inline Image
> > Editing and ensure content is compliant with Accessibility Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> >
> >
> >
> > _______________________________________________
> > Tigervnc-devel mailing list
> > Tigervnc-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Tigervnc-devel mailing list
> Tigervnc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
>
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
