00:00:00 --- log: started forth/04.01.04 00:01:43 --- join: arke_ (~chris@wbar8.lax1-4-11-099-104.dsl-verizon.net) joined #forth 00:01:45 --- nick: arke -> christmp 00:01:56 --- nick: arke_ -> arke 00:02:38 --- quit: christmp (Remote closed the connection) 01:30:40 --- join: schihei (~schihei@pD9548390.dip.t-dialin.net) joined #forth 01:50:03 --- quit: jbj (sterling.freenode.net irc.freenode.net) 01:50:37 --- join: jbj (~jbj@rdu26-59-021.nc.rr.com) joined #forth 02:14:06 wb jbj 02:30:32 --- join: schihei_ (~schihei@pD95485EE.dip.t-dialin.net) joined #forth 02:45:25 --- join: fridge (~fridge@dsl-203-33-160-64.NSW.netspace.net.au) joined #forth 02:48:18 --- quit: schihei (Client Quit) 03:08:26 --- join: scope (junk@njd.paradise.net.nz) joined #forth 03:26:46 --- quit: cmeme (Read error: 104 (Connection reset by peer)) 03:27:54 --- join: cmeme (~cmeme@216.184.11.30.unused.swcp.com) joined #forth 03:29:38 --- join: qFox (C00K13S@cp12172-a.roose1.nb.home.nl) joined #forth 03:40:32 --- quit: jbj (sterling.freenode.net irc.freenode.net) 03:40:32 --- quit: I440r (sterling.freenode.net irc.freenode.net) 03:40:32 --- quit: scope (sterling.freenode.net irc.freenode.net) 03:40:32 --- quit: skylan (sterling.freenode.net irc.freenode.net) 03:42:05 --- join: jbj (~jbj@rdu26-59-021.nc.rr.com) joined #forth 03:43:56 --- join: scope (junk@njd.paradise.net.nz) joined #forth 03:43:56 --- join: I440r (~mark4@12-160.lctv-a5.cablelynx.com) joined #forth 03:43:56 --- join: skylan (~sjh@vickesh01-4902.tbaytel.net) joined #forth 03:44:27 --- quit: I440r (Excess Flood) 03:45:20 --- join: I440r (~mark4@12-160.lctv-a5.cablelynx.com) joined #forth 04:13:29 --- join: aktnot (ident@233.80-202-65.nextgentel.com) joined #forth 04:37:35 --- join: rO| (rO_@pD9E59919.dip.t-dialin.net) joined #forth 05:31:37 --- quit: schihei_ (Client Quit) 05:38:59 --- quit: rO| (Read error: 60 (Operation timed out)) 05:57:12 --- join: rO| (rO_@pD9EE1757.dip.t-dialin.net) joined #forth 05:58:30 --- nick: rO| -> msc 06:11:23 --- quit: cmeme (Read error: 104 (Connection reset by peer)) 06:11:46 --- join: cmeme (~cmeme@216.184.11.30.unused.swcp.com) joined #forth 07:02:04 --- quit: aktnot (sterling.freenode.net irc.freenode.net) 07:02:04 --- quit: I440r (sterling.freenode.net irc.freenode.net) 07:02:04 --- quit: scope (sterling.freenode.net irc.freenode.net) 07:02:04 --- quit: skylan (sterling.freenode.net irc.freenode.net) 07:02:04 --- quit: jbj (sterling.freenode.net irc.freenode.net) 07:02:23 --- join: aktnot (ident@233.80-202-65.nextgentel.com) joined #forth 07:02:23 --- join: I440r (~mark4@12-160.lctv-a5.cablelynx.com) joined #forth 07:02:23 --- join: jbj (~jbj@rdu26-59-021.nc.rr.com) joined #forth 07:02:23 --- join: skylan (~sjh@vickesh01-4902.tbaytel.net) joined #forth 07:02:23 --- join: scope (junk@njd.paradise.net.nz) joined #forth 07:31:49 --- quit: cmeme (Read error: 104 (Connection reset by peer)) 07:42:01 --- join: cmeme (~cmeme@216.184.11.30.unused.swcp.com) joined #forth 08:08:27 --- part: aktnot left #forth 08:16:31 --- join: schihei (~schihei@pD95485EE.dip.t-dialin.net) joined #forth 08:20:14 --- join: kc5tja (~kc5tja@66-91-231-74.san.rr.com) joined #forth 08:20:14 --- mode: ChanServ set +o kc5tja 09:00:30 --- join: Herkamire (~jason@h000094d30ba2.ne.client2.attbi.com) joined #forth 09:10:15 I finished my ZUI demo. It uses SDL and OpenGL. If you'd like to try it: 09:10:16 http://herkamire.com/jason/downloads/herkforth-zuidemo-0.1.tar.bz2 09:10:42 Cool. 09:11:00 I'll have to try it when I get home tonight from work. Remind me. :) 09:16:24 z interface? 09:29:34 mur: zooming 09:29:37 kc5tja: will do 09:29:52 Cool. 09:30:41 I'm curious what framerates other people can get. because I can't seem to get the thing above about 50fps 09:31:35 Herkamire: Is your code written in C? Does it use SDL? 09:31:52 yes. C, SDL and OpenGL 09:32:25 Oops -- sorry, you already wrote that above. 09:34:56 comes with makefile for unix, but should be very easy to build for anything 09:36:53 Herkamire: got screenshots? 09:37:07 OK, I'm going to take a shower and get ready for work. back in a bit. 09:37:24 * kc5tja is away: The Three S's... 09:44:55 mur: no 09:45:37 the point is to get a feel for what it's like to zoom and pan quickly and easily through information with this kind of detail. 09:47:14 mur: you can look at my mockup though: http://herkamire.com/jason/downloads/src-zoom.png 09:47:28 it doesn't look as nice as that, but that's the general concept 09:49:50 ok 09:50:20 I can't run it. 09:50:28 I get a fatal signal, SDL parachute deployed. 09:51:18 * kc5tja is back (gone 00:13:54) 09:51:37 kc5tja: did you set a good resolution? 09:51:56 1018x700 is my screen size, considering window borders. 09:52:34 it runs fullscreen. but if you give it a size smaller than the actual screen size it should be ok 09:53:09 did it segfault? 09:55:37 Oh, that did it. 09:55:41 I had to set the full-screen resolution. 09:55:44 Yeah, it ran there. 09:56:02 I don't know if it's a segfault or not. It just says, "Fatal signal (SDL Parachute Deployed)." not a whole lot of information there. 09:57:24 weird. but it works fine fullscreen? 09:58:03 Yes 09:59:31 weird. 09:59:40 how's the interface? 10:00:44 It's OK. 10:00:54 Just don't zoom out too far though. You'll never find the block again. :) 10:02:24 :) 10:04:15 I'm thinking of having my code editor use that interface 10:05:55 Are you going to define scalable fonts, or are you going to block-scale a bitmap font? 10:06:29 not sure. I'll definately make it look nicer though 10:06:40 :) 10:06:48 I'll definately have scalable fonts at some point 10:07:10 in the short term I'll either use what I have, or just use bitmap fonts at a higher resolution 10:07:57 the whole charset (127 chars) fits in a 160x160 pixel block. 10:09:20 I could expand the characters from 10x20 to 16x32 without even making the texture any bigger 10:09:56 * kc5tja nods 10:10:00 or I could make the chars 32x64. that would render pretty well 10:10:36 I just took a screenshot of rxvt (xterm clone) and rearanged it 10:11:08 * kc5tja nods 10:12:09 I definately plan on having vector graphics 10:13:13 a ZUI kinda has to be resolution independant, so it makes sense 10:14:29 I've never done vector graphics before though, so it'll probably be a while before I have a nice renderer. (unless of course someone else writes it :)) 10:14:54 Don't look at me. 10:15:03 My primary goal is to get FS/Forth running at the Linux console right now. 10:15:17 :) 10:15:41 Thereafter, my next immediate goal would be to write my PCB CAD tool, so that I can start laying out printed circuit boards for homebrew kitting. 10:16:18 at first my graphics api will just be blitting any char anywhere at any size. Next I'll add direct access to the fb, and solid filled rectangles. 10:16:33 I'm seeing a new opportunity: software defined radios. These are radios where most, if not all, of the traditional functionality of the radio is coded in software. 10:16:39 kc5tja: cool :) 10:17:01 And I think Forth has a lot to offer this field. 10:17:22 what sort of "functionalyti of the radio"? 10:17:26 Imagine a radio that has a keyboard and VGA port for programming purposes. 10:17:37 :) 10:17:51 Modulation, demodulation, frequency selection, filtering, noise reduction, et. al. 10:18:02 :) 10:18:03 The list of features most amateur transceivers have is too long to fully include here. 10:18:37 The thing is, though, is you need a *really* high performance processor to do it all, or you need at least a DSP. 10:19:21 right 10:19:28 Consequently, a DSP chip running some dialect of Forth, complete with words for performing vector arithmetic, ought to be a nice homebrew hobby kit. 10:19:45 :) 10:19:47 hiya kc5tja ' 10:20:06 I was thinking of using an embedded PowerPC chip, like the IBM 403GA series, but I'm not sure if those would be fast enough. 10:20:13 They may require hardware assistance for some functions. 10:20:15 are DSP chips general enough to do anything you want? or are they sorta hardwired to do certain functions? 10:20:30 Even so, even if most of the radio's functionality would be coded in software, that'd be a good enough system to get started with. 10:20:49 kc5tja: that sounds really cool 10:20:53 Herkamire: They generally are general enough to do whatever you want, but they're **VERY** optimized for signal processing and streaming data work. 10:21:14 cool 10:21:26 could your radio do wifi? 10:21:40 You figure a 10MHz ADC would let you directly modulate radio signals at least up to 1.25MHz, with relatively little quantization noise. 10:21:49 Wifi? 10:22:20 I gotta go to work. 10:22:20 No more time. 10:22:26 --- quit: kc5tja ("THX QSO ES 73 DE KC5TJA/6 CL ES QRT AR SK") 10:22:33 .... 10:22:37 he didn't even say hi :( 10:23:26 arke: wanna try my zui demo? 10:23:35 wussat? 10:23:47 Zooming User Interface 10:23:52 oh 10:23:55 sweet 10:23:57 yeah 10:24:10 chris at waltoncity with a com extension 10:24:22 DCC doesn't work. 10:24:29 http :) 10:24:39 http://herkamire.com/jason/downloads/herkforth-zuidemo-0.1.tar.bz2 10:24:45 ^___^ 10:24:52 requires C compiler, SDL and OpenGL 10:26:53 got all of those. 10:26:55 er 10:27:04 however, for some reason, my 3D is fux0red :( 10:27:05 --- quit: jbj (Read error: 110 (Connection timed out)) 10:29:27 Herkamire: it just shows the EDIT screen, and nothing else 10:30:43 nothing works except for moving the screen with the mouse and quitting. 10:31:06 arke: zoom in and out with the left/right mouse buttons 10:32:46 and you're right, the code _is_ horrible ^__^ 10:33:03 don't look at the code! ;) 10:34:11 too late ^__^ 10:34:15 It's not _too_ bad 10:34:57 I got started by cutting and pasting from two tutorials 10:34:59 its really slow because I'm using mesa software because my 3D doesn't work for some fux0red reason. 10:35:03 I've never done OpenGL before 10:35:04 Herkamire: lol 10:35:26 arke: oh, it might run better if you replace "GL_LINEAR" with "GL_NEAREST" 10:35:36 * arke tries to find the place in the code that defines fullscreen mode 10:35:40 Herkamire: OK 10:36:10 arke: for smaller rendering, just change the screen size stuff at the top to 640x480 10:37:16 same speed, looks different though. 10:37:24 oh well. 10:37:47 Herkamire: yes, but I don't want fullscreen ^__^ 10:38:54 ok, just delete "| SDL_FULLSCREEN" and I think it will work 10:40:09 yay, got windows 10:40:17 yeah, thats exactly what I did. 10:40:23 * arke is teh SDL wiz 10:41:39 ;) 10:42:19 I'm not much of a wiz. I'm not interested in spending a whole lot of time learning a graphics api. 10:42:39 I like SDL because it's easy to learn the basics and they're simple 10:42:42 works quite fast now, windowed 640x480 10:42:51 yep ^__^ 10:42:59 although it's not the fastest 12:23:30 --- join: Speuler (~User@node-d-9180.a2000.nl) joined #forth 12:23:38 'morning 12:25:34 Moo. 13:16:02 --- quit: I440r ("Leaving") 13:24:37 crc has been active lately 13:25:22 --- nick: msc -> rO| 13:27:24 good evening Speuler still alive? 13:50:08 --- quit: schihei (Client Quit) 14:07:16 --- join: tathi (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth 14:50:11 --- quit: tathi ("leaving") 15:42:30 --- quit: qFox ("if at first you dont succeed, quit again") 15:53:27 --- join: I440r (~mark4@12-160.lctv-a5.cablelynx.com) joined #forth 16:21:44 Herkamire, how's your ZUI? 16:21:49 Herkamire, got screenshots yet? :) 16:22:07 slava: I have a demo avaliable. you need a C compiler SDL and OpenGL 16:22:16 http://herkamire.com/jason/downloads/herkforth-zuidemo-0.1.tar.bz2 16:23:17 ill try it right now 16:23:32 I'm now horribly depressed that I can't get it to run full speed 16:24:03 let me install SDL first :) 16:25:53 what graphics drivres are you using? 16:27:35 SDL and OpenGL 16:27:36 Herkamire, here is a problem: 16:27:45 /usr/local/lib/libSDL-1.1.so.5: undefined reference to `pthread_attr_init' 16:27:45 /usr/local/lib/libSDL-1.1.so.5: undefined reference to `pthread_exit' 16:27:45 /usr/local/lib/libSDL-1.1.so.5: undefined reference to `pthread_cancel' 16:27:48 and so on... 16:28:10 oh i need -lpthread 16:28:28 ^_____^ 16:29:06 what about this 16:29:07 /usr/local/lib/libSDL-1.1.so.5: undefined reference to `sem_destroy' 16:29:07 /usr/local/lib/libSDL-1.1.so.5: undefined reference to `sem_wait' 16:29:07 /usr/local/lib/libSDL-1.1.so.5: undefined reference to `sem_post' 16:29:23 yep 16:29:25 -lsem ??? ^____^ 16:29:42 Herkamire, can i have a pre-compiled executable? 16:29:54 Herkamire, your makefile needs work to compile on freebsd :) 16:29:59 Herkamire, but i can run a linux exe. 16:33:33 ^__^ 16:34:41 slava: no, unless you can run PPC linux executables 16:35:05 oh 16:35:09 a screenshot then? :) 16:35:35 just do: gcc gl.c -o gl `sdl-config --cflags` `sdl-config --libs` -lGLU -lGL 16:35:45 i don't have sdl-config 16:35:56 slava: I thought you installed sdl? 16:35:59 i did 16:37:15 *sigh* 16:37:17 slava: hold on 16:37:22 slava: email? 16:37:26 slava@jedit.org 16:37:38 !!! 16:37:42 you're gonna get spammed now!!! 16:37:44 ^__^ 16:37:54 i already do don't worry 16:38:00 spam-assasin takes care of most of it:) 16:39:18 you could try: gcc gl.c -o gl -lGLU -lGL -I/usr/include/SDL -D_REENTRANT -L/usr/lib -Wl,-rpath,/usr/lib -lSDL -lpthread 16:39:47 but that might be system dependant (which is what sdl-config is for) 16:40:49 --- join: tathi (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth 16:40:59 er, didnt work 16:41:03 said not allowed. 16:41:21 :( 16:42:34 arke, sure this will work, i have a restrictive firewall ;) 16:42:47 arke, email me. 16:45:33 didnt work. 16:45:36 :( 16:46:27 what didnt work? 16:46:31 that e-mail address is valid 16:46:50 odd. 16:46:52 hold on. 16:47:00 slava@jedit.org 16:47:48 " 16:47:56 "mailbox name not allowed" 16:47:57 wtf!? 16:48:26 is this a bounce from my server? 16:48:42 or a bug in your forth-based mail client? :) 16:48:43 guess so.. 16:48:48 er 16:48:53 i'm using ximian evolution.. 16:54:34 you still trying to get slava an exe? 16:54:43 geez, I'll ssh somewhere and make you one 16:58:03 don't worry 16:58:20 it doesn't really matter 16:58:54 --- quit: arke ("leaving") 17:01:15 hmmm... that box doesn't have sdl 17:01:30 that's so weird you don't have sdl-config 17:05:26 i guess the freebsd port is broken. 17:11:56 --- join: arke (~chris@wbar8.lax1-4-11-099-104.dsl-verizon.net) joined #forth 17:14:41 slava: how sure are you thaht you don't have sdl-config? everything I've read and the examples and stuff all use it to build sdl programs 17:14:52 locate sdl-config gives no output 17:15:00 slava: did you updatedb? 17:15:03 --- join: chrisrw (~chris@wbar8.lax1-4-11-099-104.dsl-verizon.net) joined #forth 17:15:04 --- quit: arke (Read error: 54 (Connection reset by peer)) 17:15:27 Herkamire, plz don't waste your time trying to fix my broken system :) 17:17:15 ^_^ 17:17:36 --- nick: chrisrw -> arke 17:17:45 slava: did you updatedb? 17:19:57 yes 17:21:53 I love all of you. 17:21:58 ^_^ 17:26:47 --- join: kc5tja (~kc5tja@66-91-231-74.san.rr.com) joined #forth 17:26:47 --- mode: ChanServ set +o kc5tja 17:28:28 hiya kc5tja 17:28:30 ^__6 17:28:32 ^__^ 17:28:34 whats up? 17:28:45 Had a really good day at work for the third time in a row. 17:28:47 question: Have you done alot of graphics programming etc? 17:28:51 kc5tja: yay! :) 17:29:06 cool :) 17:29:21 arke: No, not really. 17:29:22 * I440r didnt sleep last night but had 2 hours nap this afternoon 17:29:27 I've only done some simple stuff. 17:29:44 arke what sort of gfx stuff are you interested in 17:29:52 * kc5tja will have a lot more experience when he gets FS/Forth finished though. 17:29:56 thats something ive been seriously thinking of getting into in a big way 17:30:12 My first commercially-related task with FS/Forth is the construction of my printed circuit board layout tool. 17:30:24 Well, I've done some SDL stuff etc. 17:30:29 I know how bresenham workds 17:30:43 but I haven't messed with anything else than SDL and BIOS VGA 17:30:52 (although I did some minor tinkering with VESA) 17:31:07 And I just wanted to know what people think the best graphics "interface" is 17:31:09 err sdl is ok but im more a "i wanna do it myself" kinda coder 17:31:16 I440r: I noticed ^_6 17:31:18 Working with SDL, VESA, and whatnot is pretty much all that's truely necessary for graphics work. 17:31:19 i wanna make a gfx engine for isforth using theh frame buffer 17:31:23 eventually 17:31:25 OpenGL renders into things like SDL buffers and such. 17:31:34 including BSP and full vector graphics 17:31:37 OpenGL will render into most things :) 17:31:42 oh yeah 17:31:46 might have to wait till i have th eassembler done tho so i could use FPU shit 17:31:49 whats the difference between vector and pixel? 17:32:01 a vector is a direction and a distance 17:32:06 arke: A vector is a value that has a direction. 17:32:11 and distance 17:32:12 er 17:32:20 A pixel is an indivisible picture element. 17:32:25 a vector is an element of a set known as a vector space, and a vector space has a few special properties. 17:32:28 that is all 17:32:37 oh 17:32:39 so 17:32:46 vectors are basically movable lines 17:32:48 ^_ 17:32:50 ^_^ 17:32:52 Vector graphics are described mathematically; bitmaps are described in terms of pixels. 17:32:58 they are basiclaly LINES lol 17:33:00 that makes sense 17:33:09 arke, from any element in a vector space, you can find a mapping to a list of integers 17:33:12 hrm, cool. 17:33:13 I440r: The vector's 'distance' is its magnitude, which is what I consider it's "value." 17:33:19 arke, a list of numbers sorry 17:33:24 arke, so a vector is a list of numbers 17:33:26 kc5 ok ill go for that :) 17:33:34 arke, but if you want to do algebra on vectors, there's vector spaces and their properties. 17:33:53 transformations 17:33:57 Heh, i did a little vector stuff in math, but I didn't really get all of that.. 17:34:00 rotations scaling etc 17:34:06 hrm. 17:34:09 X is bitmap, right? 17:34:14 ive done NONE of it - but that doesnt mean i cant code it :) 17:34:21 arke: That's why I'm keeping it simple: a vector is a quantity with a direction -- it points to someplace else. 17:34:33 arke: X can do both bitmap and vector graphics. 17:34:38 hrm. 17:34:42 When you call XDrawLine(), you're asking it to render a vector. 17:34:47 kc5 it can? i actually didnt know that lol 17:34:52 When you call XBitBlt(), you're asking it to place a bitmap. 17:35:24 What X does not do is the necessary coordinate transforms to get device-independent coordinate spaces and the like. 17:35:34 --- join: TheBlueWizard (TheBlueWiz@pc84dn1d.ppp.FCC.NET) joined #forth 17:35:34 --- mode: ChanServ set +o TheBlueWizard 17:35:38 hiya all 17:35:46 hi TheBlueWizard 17:35:53 hiya arke 17:35:57 Generally speaking, it's not needed, but when doing things like desktop publishing, well, it is obviously predicated on device independent coordinate spaces. 17:36:18 kc5tja: this is cool, so if you have a vector based system, zooming, rotating, scaling, moving, etc., is alot easier, right? 17:36:26 arke: Yes. 17:36:32 Complex shapes become polygons. 17:36:45 * kc5tja notes that MacOS X's basic display technology is all vector-based. 17:36:54 ^_^ 17:36:56 bu 17:37:18 but displaying, say, a BMP file, would be slower in a vector based system, right? 17:37:21 Moving a window in MacOS X involves just moving a single composite graphic element -- the display driver is responsible for updating the display properly, because all subordinate elements are children of the window's containing object. 17:37:28 arke: No, not necessarily. 17:37:58 arke: If you're going to zoom, skew, or whatever, then obviously the bitmap needs to be post-processed. But once the new bitmap is generated, it can be bit-blitted just as fast as any other bitmap. 17:38:15 how so? 17:38:31 if all you can have is lines, basically? 17:38:38 Well, do YOU want to spend a few milliseconds zooming/skewing a bitmap every single time you want to redraw the screen? 17:38:45 arke: You asked about bitmaps. 17:38:49 100000 lines all of length 1 isn't gonna be very fun :( 17:38:58 er\ 17:39:07 i meant representing bitmaps in vectors 17:39:08 arke: computer monitors are pixel-based 17:39:09 ^_^ 17:39:36 arke: nobody represents bitmaps as vectors 17:39:55 er 17:40:01 then how does it do it? 17:40:05 arke: Well, that's silly. Even PC/GEOS, a DOS-based OS environment, represented bitmaps as bitmaps. It's just that bitmaps were contained inside the vector-based GUI. It could optionally perform scaling and the like, but doing so was pretty slow. 17:40:52 A Vector-based user interface still has to have something like X or Windows or whatever as it's rendering back-end. 17:40:57 * TheBlueWizard is not exactly sure what kc5tja and arke are arguing over 17:41:01 So it still has to deal with bitmaps at some level. 17:41:04 rotating, scewing, and scaling bitmaps is slow, but if you have a graphics system that supports those, and you use those features, it will do it. usually slowly 17:41:19 Hrm. 17:41:23 oh 17:41:25 I get it. 17:41:44 Herkamire: You can rotate images much faster, even in software, if you think about it differently. The idea is to treat the source image as a series of line patterns, then draw the new image using line draws. 17:41:47 TheBlueWizard: arke asked whether displaying bitmaps on a vector-only display system would be slow. 17:41:50 Is the bitmap blitted inside a box created by 4 vectors specially marked as such? (or is that one possible approach?) 17:42:14 arke: the point is that there _are_ no vector-based display systems (basically) 17:42:25 everything is pixels at bottom 17:42:33 vector stuff is then built on top of that 17:42:40 tathi: I think he's asking about the API-level, not at the lowest level. 17:42:47 yeah. 17:42:48 tathi: ah...that is dependent on how it is implemented...software? hardware? a combo of both? too many answers :) 17:43:10 3d graphics are vecotrs forming polygons, right? :) 17:43:22 Well, if you represent your screen as a display list, then have your display driver visit the list when it needs to update the screen, the driver is responsible for doing so in the fastest possible way. 17:43:22 well still, API or lowest level, the answer ist still that you deal with bitmaps as bitmaps, and vector stuff as vectors 17:43:49 using dirty vectors, is my guess ^_^ 17:44:13 (they call them dirty pixels, so do they call them dirty vectors too?) 17:44:14 arke: In a vector-based display, you typically represent the screen as a scene graph -- e.g., each node contains an instruction on how to render the screen. 17:44:28 One type of instruction is, obviously, "bitmap." E.g., blit this bitmap here. 17:45:08 aah, I get it. 17:45:20 kinda like "vector assembly" ^_^ 17:45:41 More or less. 17:45:54 What makes a GUI "vector-based" is primarily decided on who is responsible for walking that vector list. 17:46:22 hrm, a vector system seems relatively easy to implemetn.. 17:46:25 If it's the application, then it's considered a bitmap-based GUI. So while X11 can draw vectors, it doesn't take it upon itself to maintain window contents as lists of vectors. Therefore, it's still considered a bitmap-based GUI. 17:47:00 But MacOS X, OTOH, does represent screen contents excluseively as vector lists, and its device driver is responsible for walking the tree of vectors. Therefore, it is considered a vector-based GUI environment. 17:47:53 vector stuff seems much faster than bitmap stuff. 17:47:56 is that right? 17:48:12 Yeah, they are. But implemented naively, they can be moderately slow. The driver needs to be intelligent about what parts of the screen to update and all. 17:48:24 Why would it be any faster? 17:48:32 I don't know, just seems like it. 17:48:43 Well, yes and no. 17:48:48 It depends on what perspective you take. 17:48:57 well, compare OSX to X ^_^ 17:49:03 xf86, that is 17:49:05 A vector-based GUI system involves much less interprocess communications to support, so it's faster in that sense. 17:49:21 But as far as actually drawing to the screen . . . that's entirely up to the device driver/rasterizer. 17:49:56 X11 with backing store is about as fast as OS X. But it consumes much memory. 17:50:07 backing store? 17:50:18 In fact, I'd easily say that backing store is the fastest possible GUI system, and it's entirely bitmap based. 17:50:44 When you overlap one window onto another, the obscured region of the obscured window is discarded. 17:50:45 * arke googles 17:50:59 Thus, when exposed, the GUI has to ask the application to re-render that region. 17:51:02 This takes some amount of time. 17:51:15 Backing store means that X11 keeps a back-up of the obscured region in an off-screen bitmap. 17:51:27 So that when the window is re-exposed, it just blits the obscured region back onto the screen. 17:51:33 The application needn't be aware that this is even happening. 17:51:42 oh neat. 17:51:45 ^_^ 17:52:00 It's not rocket science. AmigaOS has been doing this since 1984, with a monsterous 256K of RAM in the Amiga 1000. 17:52:17 This is largely why AmigaOS is **so** much faster than competing GUI systems. 17:52:19 unless that area changed 17:52:22 Wrong. 17:52:29 what baffles me is the algorithm(s) used to find just the regions of a window to display. 17:52:37 the changes go into the backing store ? 17:52:40 When the graphics.library (in AmigaOS's case) detects a render to the off-screen bitmap, it will actually draw into the off-screen bitmap. 17:52:50 right 17:52:51 Yes. 17:52:51 amiga 17:52:55 not x lol 17:52:57 It does it for X11 too. 17:53:01 I find that it does. 17:53:07 err now that i didnt know 17:53:30 x apps have to redraw when exposed - or can x do that for them too ? 17:53:37 Now, the backing-store technique has a fatal flaw in this world of flashy GUIs: you cannot represent transparent windows with it. 17:54:06 i wouldnt call that a flaw, transparaent windows are just eye-wash 17:54:11 eye candy 17:54:13 I440r: If backing store is enabled, and the X server supports it, then the X server is responsible for rendering the window contents. No redraw message is sent. 17:54:19 transparent windows are major CPU-hogging eye candy ^_^ 17:54:20 IIRC on AmigaOS there are three options regarding the obscured region: ask the app to redraw it, back store, and, um....I forgot the third one :) 17:54:36 I440r: Transparent windows have uses in error reporting and command/status windows. 17:54:40 see i KNOW i gott actually study X but im gona wait till im ready with isforth lol 17:54:46 ive only browsed it a little 17:55:03 TheBlueWizard: Only two options, which you list. 17:55:39 * TheBlueWizard hmms...he thought there are three options...he will have to refresh himself at some point (pun intended :) 17:55:52 TheBlueWizard: The third "option" isn't related to that at all, actually; it's called "SuperBitMap", which IS backing store, BUT with the application-maintained bitmap. That enables a quick-and-dirty "huge bitmap" support for intuition.library to use. 17:56:10 that's the one 17:56:21 * warpzero is back (gone 24:54:26) 17:57:05 the SuperBitMap allows for easy scrolling in any direction, from an app's standpoint 17:57:07 i miss intuituin :( 17:57:25 oh yea i remember that - larger than the display 17:57:33 the display is just a window on the super bitmap 17:57:51 The nice thing about display-lists is that it provides much of the advantages of backing-store (in a way, it's a high-level backing store), but it does so in a more mathematical way. So yeah, it is more CPU intensive, but for displays comparable to normal bitmap-based displays, the overhead isn't quite so much. 17:58:12 And it is arguably vastly superior to anything else when in the presence of interprocess communications. 17:58:35 BUT....when you have exclusive access to a framebuffer, all this is moot anyway. :D 17:58:51 Which is why I love the concept of FS/Forth talking directly to SDL for its PCB interface. 17:59:13 --- join: proteusguy (~proteusgu@216.27.161.121) joined #forth 17:59:52 The only thing is, I have no idea how I'm going to implement text rendering. I'm thinking I'm just going to use a bitmapped font for my work. 18:00:02 I don't have any need for TTF fonts. 18:01:57 --- quit: tathi ("leaving") 18:06:23 ^_^ 18:06:39 Hrm. 18:06:54 * arke wants an OSX box :( 18:07:06 and/or apple publishing an x86 version. 18:07:29 not that there is alot to be done, darwin is basically FBSD, which runs fine on x86 18:08:59 The problem is the GUI is Apple-hardware specific, and you're not likely to see an x86 clone of Quartz any time soon. 18:10:49 possible, it would just take one hell of an effort ^_^ 18:11:12 OSX supports X11 apps, which is odd. 18:11:18 but, well... 18:11:19 heh 18:11:36 OSX requires a distribution of X11 for it though. 18:11:41 Out of the box, it doesn't run X applications. 18:11:51 You could write a library clone that utilizes X, but it'd jus tbe slow as all hell 18:11:57 But I think the X server is a free download though. 18:12:04