more windows on unixpc (screen memory)

[Gil Kloepfer Jr.]

In article <757 at ivucsb.UUCP> todd at ivucsb.UUCP (Todd Day) writes:
>In article <482 at limbic.UUCP> gil at 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 at 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 at icus.islp.ny.us