Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!wuarchive!emory!mephisto!udel!mmdf
From: I5110401%DBSTU1.BITNET@cunyvm.cuny.edu (Hello world !!)
Newsgroups: comp.os.minix
Subject: Re: ST 1.5 patch2.uaa (1/3)
Message-ID: <29283@nigel.ee.udel.edu>
Date: 3 Sep 90 19:54:37 GMT
Sender: mmdf@ee.udel.edu
Lines: 30


"Felix A. Croes" <croes@FWI.UVA.NL> writes :
>meulenbr@cst.philips.nl (Frans Meulenbroeks) writes:
>>[stuff deleted]
>>   HARD_SCROLL is gone. It required 32k for each console, and the gain
>                        ^^^^^^^^^^^^^^^^
>>   was not that big any more with the reworked stvdu, that I considered
>>   it worthwhile to give up 2 * 32k for it.
>
>You mean for each virtual console? That is not nesseccary. Instead of
>2 * 32k * no_of_virtual_terminals, only 32k + 32k * no_of_virtual_terminals
>should be needed, if the code is written right.
Yes, that might work. Haven't thought about it yet. But it implies that one
has to copy 64 KB on every virtual console switch, or do i overlook some
points here ?

>It might be even better to keep a copy of the characters on the screen in
>memory, instead of a copy of the screen image. The speed penalty should be ver
>small, only the screen buildup after a console switch is much slower.
>Or are you intending to add screen graphics?
I thought about this when when i was about to rework stvdu.c. I decided that
(a) it would be a lot of changes to the existing code. The current virtual
    console implementation has not involved that big changes.
(b) maybe there will be screen graphics some time in the future, and then
    the whole screen contents must be saved anyway.
However, the much smaller memory allocation for virtual consoles makes it
very interesting for people with memory shortage.

--
Kai-Uwe Bloem, i5110401@dbstu1.bitnet