Xref: utzoo comp.sys.att:6271 unix-pc.general:2802 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!rutgers!att!icus!limbic!gil From: gil@limbic.UUCP (Gil Kloepfer Jr.) Newsgroups: comp.sys.att,unix-pc.general Subject: Re: more windows on unixpc (screen memory) Summary: I need it for other device drivers Message-ID: <484@limbic.UUCP> Date: 28 Apr 89 23:03:22 GMT References: <677@icus.islp.ny.us> <482@limbic.UUCP> <757@ivucsb.UUCP> Reply-To: gil@limbic.UUCP (Gil Kloepfer Jr.) Distribution: na Organization: ICUS Software Systems, Islip, NY Lines: 40 In article <757@ivucsb.UUCP> todd@ivucsb.UUCP (Todd Day) writes: >In article <482@limbic.UUCP> gil@limbic.UUCP (Gil Kloepfer Jr.) writes: >~So, correctly speaking, what should really happen is: 1) have AT&T increase >~the amount of windows compiled-into the window driver [a memory waste for >~those who don't use a lot of windows], > >But won't the new window driver just eat more kernel memory? It seems to me >that there is a LOT of unused kernel memory, and adding a few more window >structures doesn't seem like it will put a real drain on available kernel >memory... >-Todd Day- >Internet: todd%ivucsb.UUCP@anise.acc.com Yeah, it *will* eat more kernel memory...which I would like to have available for device drivers for other things .. like maybe the proposed SCSI board being worked on, voice power board, my own device drivers, etc. Although it's THERE, it's not there to waste. If the window driver is to use memory like it does, the parameter should be tunable, or it should allocate/free virtual memory at window create/delete time (if it doesn't already). I suspect it *does* use kernel memory, for a multitude of reasons too complex (and a little beyond my knowledge of the kernel) to explain here on the net. Most of us out here have no need for the extra windows. Unless you use the user agent (which, I may add, could use window resources much more efficiently), you will rarely, if ever, exceed the window limitations of the machine. I'm sure someone has a non-ua-based pet project which is an exception to this rule, but it seems to me that my statement is more the rule than the exception. Again, if someone didn't respond already with the correct answer, my understanding is that the bitmap for each window is saved somewhere other than in screen memory for the sole purpose of being able to restore windows which were temporarily occluded by another window at some time. Since these bitmaps are large (or can become large), I do feel that they should not be there unless "allowed" (like with a tunable parameter). ----- | Gil Kloepfer, Jr. | ICUS Software Systems/Bowne Management Systems (depending on where I am) | {decuac,boulder,talcott,sbcs}!icus!limbic!gil or gil@icus.islp.ny.us