Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!uunet!iscuva!jimc From: jimc@iscuva.ISCS.COM (Jim Cathey) Newsgroups: comp.sys.mac.programmer Subject: Spleen venting (was: Re: 32-bit OS) Message-ID: <2601@iscuva.ISCS.COM> Date: 22 Aug 89 16:10:42 GMT References: <22321@andante.UUCP> <1989Aug19.221033.2241@geology.wisc.edu> <8352@hoptoad.uucp> <34184@apple.Apple.COM> Organization: ISC Systems Corporation, Spokane WA Lines: 73 In article <34184@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >In article <8352@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >>Want to display a bitmap or picture with more than 32,767 pixels in a >>scrolling window? Better write your own scroll bar CDEF then, and set >>up your own versions of the value etc. routines, because the Control >>Manager can't imagine you would ever want a 32-bit control. Same goes >>for text -- want to display more than 32,767 lines in a scrolling text >>document? Don't look to the OS for help, except for drawing the >>characters! >Sounds like a job for MacApp! MacApp allows views to have 32-bit coords... Oops, something just slid over my reasonableness threshhold, so watch out! (Not picking on anybody in particular, it's just that I keep hearing things like this and I can't let them slide forever.) FLAME ON **** It's not just the CM that can't imagine anyone needing (not wanting) a long, I can't either. Why not just scale the control? Do you really _need_ more than 32767 discrete settings for a control? Why? Usually when scrolling through bitmaps a chunk size of 8 bits is more reasonable than 1 bit anyway, so using each increment of 1 of the scrollbar to move 8 pixels yields a document size of about 300 feet! (262,000 pixels.) In MacPaint terms this represents an in-memory bitmap of 18MB in size (for _monochrome_)! Isn't that big enough yet? Make the chunk 9 or 10 pixels if it isn't. Consider that >32767 settings of a scroll bar mean that the operator will find it very difficult to use the thing to find a position anyway. Each pixel of the control (say about 400 to be generous) represents 82 different settings of the control. Controls live in the human interface space, not the program convenience space. If you find you're wanting more range than is available it's because you haven't decomposed the problem correctly. The complaint about TE has been dealt with already. By the time you get that many lines TE has bogged down to the point that you don't want to use it anyway. Hell, if all I wanted to do was scroll through a huge number of lines of text I'd probably not even blink about doing it myself -- especially since I'd probably 'chunk' the document in from disk piecemeal so's not to waste memory having my mongo document in memory all at once. Those putative 40,000 80-column lines take up 3.2MB all by themselves. C'mon guys, MoveTo and DrawText are _easy_! Lord help us when the Mac has VM -- hardly anyone one will ever even try to appease the effeciency gods. The Vax weenies [Paging Will Fix It (tm)] will dance upon our graves yet (chanting "More megabytes, more megabytes..."). I _like_ the 16-bit integers and all that entails. They serve as a constant reminder to _think_ about what ranges I need, and why. The long is there for when they won't serve. I suppose spending a few minutes thinking about things _is_ too much for some, but let's let them continue to bang their shins on real-life systems and piss-n-moan about it. _We_ know better don't we? Sooner or later they'll learn, and we'll all be better off. We won't appease the uninformed by breaking our tools so they're less efficient. (You know, 32-bit ints, >32K globals for huge static arrays, VM, things like... oh-oh!) FLAME OFF **** +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC-Bunker Ramo ! II CC ! TAF-C8; Spokane, WA 99220 ! IISSSS CC ! UUCP: uunet!iscuva!jimc (jimc@iscuva.iscs.com) ! II CCCCCC ! (509) 927-5757 +----------------+ "With excitement like this, who is needing enemas?"