Date: Thu, 16 Feb 95 09:55:14 GMT From: "Acacio Cruz - MIS" To: djgpp AT sun DOT soe DOT clarkson DOT edu Subject: GRX enhancement possibility (?) Reply-To: acruz AT pt DOT oracle DOT com Original-To: PTUNIX:djgpp AT sun DOT soe DOT clarkson DOT edu Csaba, I've been using your GRX 1.03 and there's on sugestion I want to make so that maybe you can include it in 2.0. Well, there's already a queue of events managed by you but "what if" one wants to implement event-driven applications and wants to get good management of event queues? The solution I managed to get working is: Initialize GRX Redirect Mouse handler to a new handler and call the previous (GRX) mouse handler within my handler. I'll send you the code if you want BUT wouldn't it be cleaner and safer to provide a event handler registry to be daisy-chained to your event-handler routines. This way one could get even-driven AND GRX to work together CLEANLY. Hope this helps, -Acacio / | /\_/\ Auf Auf ... (- -) ----------------------------oOO--\_/--OOo------------------------------- Acacio Cruz Morada/Address: MIS, Mailkeeper, Network Manager Rua General Ferreira Martins, 8, 4A Oracle Portugal Alges 1495 Lisboa - Portugal Mail: acruz.pt T: (351) +1 4109666 Fax: +1 4108741 ........................................................................ Q: Why do stars twinkle? A: Bad connection in the power grid. We're working on it. ---- Included Message ---- Received: 02-15-95 20:05 Sent: 02-15-95 12:19 From: PTUNIX:djgpp-bounces AT sun DOT soe DOT clarkson DOT edu To: djgpp AT sun DOT soe DOT clarkson DOT edu Subject: Re: Graphics under Windog... Reply-To: PTUNIX:djgpp-bounces AT sun DOT soe DOT clarkson DOT edu About linear memory mapping: IT IS NOT WORTH THE HASSLE. Consider this: if you do graphics which is at least a little structured (you touch at least a few hundred pixels before a 64K boundary crossing -- line drawing, etc all falls into this category.) then the overhead of a function call and a few out instructions is really negligible next to the time your CPU spends in wait states until your video card is ready to accept the next pixel written. Yes, even your whiz-bang VESA LB or PCI card is pityfully slow compared to the system memory in your 486 or Pentium. Enabling linear memory addressing on a non-accelerated SVGA, even if it is local bus, is NOT the thing which will automagically turn your PC into a Silicon Graphics. If that's what you want then buy an SGI or at least an accelerated video card. As far as the possible performance gains are concerned, you can get a good idea by writing a small program using GRX which fills, say, a 100x40 rectangle in the 1024x768x256 mode. Position it once within the same bank, once such that it crosses a bank boundary, run it a couple thousand times, and time the difference. This is the gain you would get by using linear memory access. I haven't done this recently, but I did it some time ago, and the difference was really negligible (a few percents). Properly written banked frame buffer codes (what I am just doing for GRX 2.0) can actually be slightly faster than the GO32 virtual VGA banking. But again, we are talking about a few percent difference. The arguments against linear memory mapping are numerous: it depends on many factors, including VGA chip type, installed memory, bus type, memory manager (EMM386, DPMI host, etc...). At best, this would lead to a proliferation of drivers (currently most drivers for a certain chipset can be used on the ISA, VLB and PCI versions of the same card) -- when the driver situation is already getting out of hand. At worst this would lead to many more of the "help-my-graphics-is-not-working-on-my-pc-with-this-and-this-card-and-this-is- my-environment-setting" posts of which we have already seen too much. Additionally, in the DPMI compliant GRX this would require a completely new set of frame driver codes, next to the banked ones which have to be there for those people who cannot map their cards linearly => code bloat, etc... About the new GRX: GRX 2.0 is out for alpha testing. (Note ALPHA, not BETA!!) Send me an e-mail and I will tell you where you can get it. You can compile it with DJGPP v1.1[12]m* ALPHA status means that: 1) it is incomplete and possibly quite buggy, 2) in general, you should know what you are doing before you touch it, 3) most likely your exisiting GRX program will not work with it, and 4) detailed bug reports are especially appreciated. Before everyone gets very excited here is the current status: - basic stuff (lines, rectangles, filled rectangles, etc..) works in 16, 256, 32K, 64K and 16M EGA/VGA modes. - works under DPMI and Linux (using svgalib for video mode switching) (according to Charles it also works with CWSDPMI and maybe NT???) - NO: * text drawing * complex shapes (circle, polygon, etc...) * patterned lines and fills ==== these routines are moved over from 1.03 as time permits ==== * manual (most of the 1.03 manual is still applicable, if it disagrees with the code then the code is right 8-) ) * support for accelerated chips for now. - the good news: the test programs from GRX 1.03 which do not use features listed above seem to build and run OK in all environments and video modes. - still uses the Turbo C make, and will continue using it until it is possible to reliably run 2..3 levels of nested make-s and a gcc in the DJGPP environment. - 64K banked frame buffer codes (no reliance on GO32 virtual VGA mapping any more) => all HiRes modes work in 16 bit (TurboC) versions as well! Most of these are optimized, some are still quite crude and slooooow. - has drivers for EGA VGA ET4000 CIRRUS54 and VESA (DOS and derivatives) svgalib (Linux). These are all part of the library now. As the driver spec is already quite stable, ALPHA testers willing to come up with new drivers would be especially appreciated. Csaba