Date: Mon, 14 May 2001 16:48:15 -0700 From: "L. Peter Deutsch" <ghost@aladdin.com> To: mi@aldan.algebra.com Cc: ports@freebsd.org, andreas@freebsd.org, raph@artofcode.com Subject: Re: GhostScript and JPEG Message-ID: <200105142348.QAA00167@aladdin.com> In-Reply-To: <200105142334.f4ENYJq14093@misha.privatelabs.com> References: <200105142334.f4ENYJq14093@misha.privatelabs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> It appears, that the only thing, that makes it necessary for GS to build > its own static version of JPEG library is the value of > > D_MAX_BLOCKS_IN_MCU > > To read some JPEGs embedded in some PS files, GS needs this to be set as > 64, while the default libjpeg compiles this as 10. Correct. > I'm wondering, if we should just make our graphics/jpeg port build with > the define set to 64 and make GS use the shared -ljpeg. > > This would increase the size of some arrays (of pointers or of integers) > from 10 to 64 -- con. On the pro -- faster port build, faster startup > usually, since libjpeg is so widely used already. > > Any comments? Thanks! Sure, I think that would be a fine idea. The only arrays that are dimensioned as [D_MAX_BLOCKS_IN_MCU] are some temporary arrays of booleans and pointers allocated on the C stack within libjpeg, and an array of ints in the decompression state structure. So increasing this value from 10 to 64 increases the size of the decompression state structure by (64-10)*4 = 216 bytes. Not enough to worry about. -- L. Peter Deutsch | Aladdin Enterprises | 203 Santa Margarita Ave. ghost@aladdin.com | http://www.aladdin.com | Menlo Park, CA 94025 The future of software is at http://www.opensource.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105142348.QAA00167>