nanogui: Thread: Blitting

yet more spam to the list...

I'm interested in using some sort of "fast screen to screen" blit in an
application I'm working on. Do we have anything like that that works,
I've noticed commented out blit-code in nterm, etc. but Enabling it
doesn't seem to do much, I've read the nanox source code but it's like
beating my head against a brick wall, Greg, anyone, please?

	-Darran

--
 Darran D. Rimron            European Research & Development Manager
Real Data Services, 117-119 Marlborough Road, Romford, Essex, RM7 8AR
 ####@####.####                      http://www.getreal.co.uk/
 Phone:44-1708-70-44-33 Fax:44-1708-74-88-59 Mobile:44-7931-37-59-39

: I'm interested in using some sort of "fast screen to screen" blit in an
: application I'm working on. Do we have anything like that that works,
: I've noticed commented out blit-code in nterm, etc. but Enabling it
: doesn't seem to do much, I've read the nanox source code but it's like
: beating my head against a brick wall, Greg, anyone, please?

Darran,
	Blitting only means something when off-screen
drawing is supported.  It's done in Microwindows but not
yet in Nano-X.  This involves implementing the GR_PIXMAP_ID
in GsPrepareWindow so that all draw routines can take
either a window or an offscreen pixmap.  Then a blit routine
can be called to copy the offscreen to screen.

In addition, screen-to-screen blitting is implemented,
but not yet in Nano-X.  This will be done through a new
routine, GrCopyArea, like Xlib.  Screen-to-screen is
real nice of terminal emulator scrolling...


If this is pretty important for you, I can write it.  It's been
on the list for a while, but I just never got around to it.

Greg

> -----Original Message-----
> From: Greg Haerr ####@####.####
> Sent: 04 January 2000 18:04
> To: Darran D. Rimron; NanoGUI Developers Mailing list
> Subject: RE: Blitting
>
>
> 	Blitting only means something when off-screen
> drawing is supported.

I'm not "up with it" on all these terms, I'm probably faux-par'ing all
over shop :)

> It's done in Microwindows but not yet in Nano-X.

Ok....

> This involves implementing the GR_PIXMAP_ID
> in GsPrepareWindow so that all draw routines can take
> either a window or an offscreen pixmap.  Then a blit routine
> can be called to copy the offscreen to screen.

Hmmm. I'll be interested in doing screen to offscreen copies and
offscreen to offscreen copies. If that makes sense?

> In addition, screen-to-screen blitting is implemented,
> but not yet in Nano-X.

Ok, this is what I need.... :)

> This will be done through a new
> routine, GrCopyArea, like Xlib.  Screen-to-screen is
> real nice of terminal emulator scrolling...

Yep. Spot On. Exactly. Etc. :)

> If this is pretty important for you, I can write it.  It's been
> on the list for a while, but I just never got around to it.

Yes, it is, for text area scrolling....  I'm also going to be looking at
some way to copy screen data into "normal ram" for scroll back buffers
(like xterm) -- this is blitting, yes? I think. I was debating storing
the terminal data as returned by the shellIO FD but changed my mind
against that because curses based applications would be a total
nightmare....

	-Darran
--
 Darran D. Rimron            European Research & Development Manager
Real Data Services, 117-119 Marlborough Road, Romford, Essex, RM7 8AR
 ####@####.####                      http://www.getreal.co.uk/
 Phone:44-1708-70-44-33 Fax:44-1708-74-88-59 Mobile:44-7931-37-59-39

: Hmmm. I'll be interested in doing screen to offscreen copies and
: offscreen to offscreen copies. If that makes sense?

Yep.  GrCopyArea needs to be implemented.  It will look
almost exactly like Xlib's CopyArea, but won't need the GC
parameter, which is used only to find the display/screen.


: Yes, it is, for text area scrolling....  I'm also going to be looking at
: some way to copy screen data into "normal ram" for scroll back buffers
: (like xterm) -- this is blitting, yes? I think. I was debating storing
: the terminal data as returned by the shellIO FD but changed my mind
: against that because curses based applications would be a total
: nightmare....

No, using blitting to store scroll-back data will use INCREDIBLY
too much memory.  Far better to use the terminal data.  Scrollback
can stop after seeing certain escape sequences, like clearscreen,
which you'll know about since you're parsing them.

Regards,

Greg

> No, using blitting to store scroll-back data will use INCREDIBLY
> too much memory.  Far better to use the terminal data.  Scrollback
> can stop after seeing certain escape sequences, like clearscreen,
> which you'll know about since you're parsing them.

Hmm, will have to think about this alot.... Have been using the "worms"
test program from ncurses to test things. That contains alot of "goto
X,Y; Plot a Char; goto X,y; Plot a Char, etc" So that could be several
tens, hundreds of K of data for a single screen, if the user was to let
it run.... Because it doesn't technially scroll the screen....

ideas, anyone?

	-Darran

: Hmm, will have to think about this alot.... Have been using the "worms"
: test program from ncurses to test things. That contains alot of "goto
: X,Y; Plot a Char; goto X,y; Plot a Char, etc" So that could be several
: tens, hundreds of K of data for a single screen, if the user was to let
: it run.... Because it doesn't technially scroll the screen....
: 
: ideas, anyone?

You're confusing current screen refresh with scrollback.  Anything
drawn on an 80x24 screen needs to be saved for refresh.

Scrollback addition is only required when the terminal emulator
scrolls it's screen by some number of lines.  Those lines scrolled
off the top are added to the scrollback buffer.

Greg

> -----Original Message-----
> You're confusing current screen refresh with scrollback.  Anything
> drawn on an 80x24 screen needs to be saved for refresh.

Agreed. I'm not going to tackle this quite yet, as my device/use won't
use VT switching, I'll add it in later when I'm in the "adding toys"
stage :)

> Scrollback addition is only required when the terminal emulator
> scrolls it's screen by some number of lines.  Those lines scrolled
> off the top are added to the scrollback buffer.

Agreed again. I was refering to scrollback.  If I'm storing every
character that is plotted from the ShellIO FD to generate the scrollback
then I'm storing alot of data, yes?
If the display is scrolled a line (by hitting CR in at a shell prompt
for example) the line that goes off the top needs to be added to the
bottom of the scroll buffer, and if maximum length has been acheved, the
top line gets dumped.... which I understand, etc.  But how do yo suggest
I get the "content" of the top line, if I'm storing ASCII and ESC/CSI
values from the termio, there's alot of data to be stored for each
screen if you are running an application like "worms"....? Am I making
sence or just not seeing your point? Sorry.

	-Darran

> > You're confusing current screen refresh with scrollback.  Anything
> > drawn on an 80x24 screen needs to be saved for refresh.
> 
> Agreed. I'm not going to tackle this quite yet, as my device/use won't
> use VT switching, I'll add it in later when I'm in the "adding toys"
> stage :)

Most X terminal applications store an ascii grid with end markers. The end markers are
used for cut/paste to know if a line wrapped or is a real newline.

Its generally faster to redraw the relevant bits (common optimisation - dont redraw the
large empty white areas). The redrawing thing has a lot to do with the nature of PC
video - its cheap to write, expensive to read as you stall the CPU for the bus on a read
but writes are buffered.

Alan

 But how do yo suggest
: I get the "content" of the top line, if I'm storing ASCII and ESC/CSI
: values from the termio, there's alot of data to be stored for each
: screen if you are running an application like "worms"....? Am I making
: sence or just not seeing your point?

The way to do this is that the terminal emulator keeps an current
x, y cursor value.  The terminal emulator alloc's a [24][80] array
and stores each incoming character in the current cursor location.
Then when refresh is required, the contents of the array are written
in whole to the display, thereby repainting all your worms.

As Alan Cox just mentioned, you don't want to draw the space
characters for speed.  So, on a refresh, the current background
color is fillrect'ed to the display, then the non-space characters
are drawn.  There are many other optimizations as well, having
to do with drawing each line at a time, etc while the attributes
are the same, etc.

Greg

> characters for speed.  So, on a refresh, the current background
> color is fillrect'ed to the display, then the non-space characters

That makes it flicker. You dont do that. You just skip updating chars that where
space and are a space now

Alan