Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!jarthur!nntp-server.caltech.edu!toddpw
From: toddpw@nntp-server.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple2
Subject: Re: GIF Viewer
Message-ID: <1991Feb26.230754.8996@nntp-server.caltech.edu>
Date: 26 Feb 91 23:07:54 GMT
References: <538@generic.UUCP> <44722@ut-emx.uucp>
Organization: California Institute of Technology, Pasadena
Lines: 28

daveh@ccwf.cc.utexas.edu (David H. Huang) writes:

>QuickDraw II is supposed to handle "pictures" (I forgot the exact term
>for it) up to 32768x32768.

I think the term you want is a mutation of 'pixel image'. QD II's conceptual
drawing space is -16K to +16K in both X and Y, for a maximum image of 32768
pixels in each direction. Mac Quickdraw goes out to +/- 32K for a maximum
image of 65536 pixels in each direction -- this requires slightly more complex
math, and 16K pixels is a hell of a lot already, so QD II enforces a 16K limit
and is allowed to neglect some extra overhead as a result. Unfortuneately,
there's still some pretty beastly overhead in the rest of the system (region
processing).

>I think the reason for the 64K limit is that it's hard to
>manipulate data that crosses a bank boundary, especially in C.

That's totally incorrect. Orca/C may have a couple of bugs when it comes to
address calculation but that does not prevent you from working with rather
large arrays.

If the _commercial_ version of SHRConvert does not go past 64K then I can't
possibly respect Jason Harper as a programmer. From day 1, the Lord High
GIFfer has been chomping on an 800x600x256color picture as one of it's test
cases.

Todd Whitesel
toddpw @ tybalt.caltech.edu