Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-spam!mordor!lll-tis!ames!ucbcad!ucbvax!COGSCI.BERKELEY.EDU!bryce
From: bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt)
Newsgroups: comp.sys.amiga
Subject: Re: simpe_refresh console device / layers
Message-ID: <8707010639.AA14094@cogsci.berkeley.edu>
Date: Wed, 1-Jul-87 02:39:08 EDT
Article-I.D.: cogsci.8707010639.AA14094
Posted: Wed Jul  1 02:39:08 1987
Date-Received: Fri, 3-Jul-87 00:47:45 EDT
References: <150@sugar.UUCP> <1219@crash.CTS.COM> <347@sol.ARPA> <1230@crash.CTS.COM> <195@sugar.UUCP>
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 22
Keywords: simple_refresh, smart_refresh, console.device, warptext, blitzfonts

In article <195@sugar.UUCP> peter@sugar.UUCP (Peter DaSilva) writes:
<
< [I'd like to write a simple_refresh console.device...]
<>
<> [But smart_refresh is so much faster...]
<>
< The problem is that if you have a bunch of smart-refresh windows on the
< screen, and do much window manipulation, they each get chopped up into a
< whole bunch of super-small bitmaps and updating becomes pure agony. Simple
< refresh is slightly (slightly! If you use a single Text() call for each
< line of text you output, it's damn fast) slower for the simple case, but
< its behaviour doesn't degrade nearly as badly.

To toss an obvious idea out...  how about a priority -200 task that coagulates/
optimizes cliprects and frees the extra chip memory taken up by the above
situation?

A single Text() call with BlitzFonts installed is even faster, and rumor
has it that WarpText [see comp.sources.amiga] is faster yet.  Console
devices often are nearly all only one plane, but also can have color...

	Inews. grumble, gritch.