Path: utzoo!utgpu!watmath!att!dptg!ulysses!atti07!mjm
From: mjm@atti07.ATT.COM (Michael Matthews x7776)
Newsgroups: comp.sys.att
Subject: Re: general purpose bit blitter
Summary: one wrastop() after painting pixels in memory.
Message-ID: <298@atti07.ATT.COM>
Date: 20 Oct 89 19:11:43 GMT
References: <WJC.89Oct16104701@hoswjc.hoswjc.ATT.COM> <1989Oct19.161204.3420@sun.soe.clarkson.edu>
Organization: AT&T International, Basking Ridge, NJ
Lines: 19

In article <1989Oct19.161204.3420@sun.soe.clarkson.edu>, dean@image.soe.clarkson.edu (Dean Swan) writes:
> Along the lines of RAM access, I need to plot waveforms and such in a window.
> I wrote a line drawing routine that calls WRASTOP, but it is painfully slow.
> I suspect that it is because WRASTOP issues a refresh to the window, before
> doing a blit evertime it is called.  I've thought about reimplementing it to
> build a bitmap in user memory of the line and then just doing a single WRASTOP
> call to copy it to the window, but that seems like an awful lot of work just
> to draw a line.  Can anyone help?
> 

The wrastop() call takes as much overhead regardless of the surface screen
size updated. Why would it be more work to optimize? You already have the
solution: A 'short' array in
memory can be setup identical to the screen. Paint the screen in memory
and when finished do one wrastop() much like a curses refresh(). It will be
incalcuably faster.

Mike Matthews
ATT International