xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (10/12/90)
daveh@cbmvax.commodore.com (Dave Haynie) writes: > lron@easy.HIAM (Dwight Hubbard) writes: > >>Yes, it would also make the system more flexible since it would >>be possible to send commands to the device directly. Can you >>see drawing a picture on the screen by typing: copy xxxpic to gfx: > >That might be kind of cool. And in fact, you could write such a GFX: >filesystem, though of course that's not the same thing as pure device >independent graphics -- you don't want the overhead of a filesystem type >server to do all your graphic commands (then again, the X Windowing system >does it kind of similarly). I suppose you would want the GFX: device to >support multiple devices. A preference editor might set up the default >for GFX:, maybe as a window on Workbench. You could pick a display card >simply by name; maybe "GFX:BuiltIn" for the standard Amiga graphics, >"GFX:A2410" for that ULowell card, etc. I suppose the best thing for such >a device to do would be for it to speak in a high level graphics language >that's byte stream rather than function call based. Just like with disks, >there would be a device driver under the GraphicsSystem, and for higher >performance you could look up the particular graphics.device based on the >filing system name for the unit. Kind of weird, but interesting. Based on >the fact that it's all done in byte streams, you could do things with filters, >like: > > type pic.ilbm | ilbm_2_gfx | GFX:Builtin/640/400/4 > >Or somesuch. Similar filters could handle PHIGS, PostScript, whatever, with >enough effort. You don't want GFX: to speak ILBM as a native language, but >something much higher level, so you can send it "draw a circle", "fill this >rectangle", etc. type commands. Well, it's a little long in the tooth, but the Computer Graphics Metafile, which is nearly one to one with GKS's hardware interface, provides just such a capability, and has the advantage of being an existing international standard (three of them, more correctly, but that's another story) with the interface commands already designed to the byte and bit level. It has a small but powerful set of graphics drawing primitives, and a _very_ compact encoding. The down sides are its model of text, and its model of rasters, but both can be overcome with a bit of glue code and pain, and are capable of getting the job done. Worth a look. CGM, though, is really a passive graphics standard, meant for "put it on a tape and plot it when the plotter's free" type of applications. For anything but just blasting an existing picture described as a stream of command bytes to the screen, some higher level standard (e.g. PHIGS) bears looking at. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>