[<<] [<] Page 1 of 2 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Blitting
From: "Darran D. Rimron" ####@####.#### Date: 4 Jan 2000 15:39:15 -0000 Message-Id: <NCBBLCEDENCINNMFNPBCMEDODJAA.darran@getreal.co.uk> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: Blitting
From: Greg Haerr ####@####.#### Date: 4 Jan 2000 18:06:02 -0000 Message-Id: <C1962B36D9BBD311B0F80060083DFEFBF00B@NBA-SLAM.CenSoft.COM> : 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: Blitting
From: "Darran D. Rimron" ####@####.#### Date: 4 Jan 2000 18:15:50 -0000 Message-Id: <NCBBLCEDENCINNMFNPBCKEEJDJAA.darran@getreal.co.uk> > -----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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: Blitting
From: Greg Haerr ####@####.#### Date: 4 Jan 2000 20:43:30 -0000 Message-Id: <C1962B36D9BBD311B0F80060083DFEFBF06B@NBA-SLAM.CenSoft.COM> : 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: Blitting
From: "Darran D. Rimron" ####@####.#### Date: 4 Jan 2000 20:48:38 -0000 Message-Id: <NCBBLCEDENCINNMFNPBCOEEMDJAA.darran@getreal.co.uk> > 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: Blitting
From: Greg Haerr ####@####.#### Date: 4 Jan 2000 21:00:06 -0000 Message-Id: <C1962B36D9BBD311B0F80060083DFEFBF077@NBA-SLAM.CenSoft.COM> : 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: Blitting
From: "Darran D. Rimron" ####@####.#### Date: 4 Jan 2000 21:22:00 -0000 Message-Id: <NCBBLCEDENCINNMFNPBCGEEODJAA.darran@getreal.co.uk> > -----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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: Blitting
From: Alan Cox ####@####.#### Date: 4 Jan 2000 21:26:49 -0000 Message-Id: <E125bIV-0003Pr-00@the-village.bc.nu> > > 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: Blitting
From: Greg Haerr ####@####.#### Date: 4 Jan 2000 22:41:25 -0000 Message-Id: <C1962B36D9BBD311B0F80060083DFEFBF0C2@NBA-SLAM.CenSoft.COM> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: Blitting
From: Alan Cox ####@####.#### Date: 5 Jan 2000 01:06:36 -0000 Message-Id: <E125ejm-0003fR-00@the-village.bc.nu> > 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 2 [>] [>>] |