Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!bcm!rice!uupsi!sunic!lth.se!kberg!svante From: svante@kberg.se (Svante Gellerstam) Newsgroups: comp.sys.amiga.advocacy Subject: Re: OS Graphic Card Support: Part II! Message-ID: <1991Mar1.124149.12666@kberg.se> Date: 1 Mar 91 12:41:49 GMT References: <18989@cbmvax.commodore.com> <1991Feb18.210422.5446@sat.com> <1991Feb20.090728.2384@kberg.se> <1991Feb23.203900.27912@sat.com> Organization: Karlberg & Karlberg AB, Lund, Sweden Lines: 142 In reply to Dave Haynie -- somehow this article got lost in space between my feed and our machine. That's why references are wrong. Here it is anyway. >In article <1991Feb25.090714.3701@kberg.se> svante@kberg.se (Svante Gellerstam) writes: >>Ok, I just wanted you to spell it out for me. The thing I have been >>trying to get acceptance for (breaking down open doors?) is some >>proposal towards a DIG standard for Gfx cards. >Nothing wrong with trying. Thing is, lots of people will tell you to wait >until C= comes out with one. Seems to me that's not absolutely necessary; >if a standard is truly device independent, then you can build a soft device >driver for one standard to support all devices in another standard. I would >personally rather see programs even support two standards, rather than 100 >different low level hardware register conventions, on a per-program basis, >like they do on the PC. I, and some others I guess, are ready to do this if it weren't for the time involved in doing the job right. Our company works with importing professional products for the Amiga. We also do some development on important products, something wich may or may not grow in the future. The work I do is mainly to provide support and develop the possibilities of our new products. What I am trying to say is that I could do this for work if I had the time - I would gladly share it. A little sacrifice here usually gives a large return there. What I am trying to do now is to use the open minds of all netters to find out what the task really would amount to. I am the first to admit that I know to little now to be able to do anything important in the field. But I am aching to learn - as I see that this, for the professional user, very important field is totally unattended (bar niche solutions). There are simply NO gfx cards running WB applications, presently. There should be. >>Now, when I have you attention, I would like to hear (see :-) if you >>have any suggestions to put forward on how a device driver for ANY gfx >>card should be put together. >There are two basic approaches. The simplest is the way Microsoft Windows, >or in a sense the Bridge Card, does it. Basically, it goes something like >this. The graphics.library agent is responsible for building the bitmap in >its internal format, which doesn't necessarily correspond to any physical [ stuff deleted...] >The other approach is to treat the graphic library like an object description >language, more along the lines of the Mac's QuickDraw, HP's laser printer >command set, or Postscript (though Postscript is more far more sophisticated). [ stuff deleted...] As I see it we need a graphics.library that is basically device independent. This would mean that all present (nice) applications would run right away, problably without taking advantage of color or resolution but never the less running. Gfxlib would then talk to a device.driver of some sort. We agree this far (no?). I propose that the form of this driver is the core of the problem. I may be wrong. With that out of the the way, I merrily proceed to open fire (in current terms :-|) in a maybe wrong direction. There is a set of basic drawing commands: * Set / Get pixel * draw line * fill area (may be put into the area BLIT group of function) * other drawing primitives (circles, arcs, polygons etc) These should be easy to implement on any gfx card utilizing all resources of that card. Then there is a set of functions that may clash with abilities on board any given gfx card: * BLIT functions * Text rendering * Image rendering (pixel based gfx) They clash in the sense that the data the driver is presented with may have to be translated into another form, taking up memory and time. I guess this is why you say it's the slow way. The behaviour of the gfx.device could be of many types. I see two basic classes that are represented: * Syncronous (like today, calls to graphics.library map directly to addresses in gfx.device, via f x SetFunction()) * ASyncronous (like X-Windows does it, queue up a bunch of calls and send a Gfx_Sync command to make it appear) I vote for the synchronous in this case because it will reqire no mods or additions to the current gfx redering calls in graphics.library. The driver may do some queueing itself if that's appropiate for that specific card. That is the OS -> card high level part. The new thing is that the OS has to be able to find out, and preferably take advantage of the abilities in: * raw pixel resolution * Display DPI (for scale sensitive apps. DTP, CAD etc) * number of colors * possibly other esoteric functions of the card (like genlocking in an external video signal in a window etc.) These has to be taken care of through a new set of calls (I assume, knowing little about these things under WB 2.0) The main difference here is that any given users Amiga may have any number of available resolutions. We cannot rely on things being static, with Commodore handing out new ScreenMode flags to accepted resolutions. Instead the user should by menu select from the available resolutions the one WB should run on etc. Apps. has to have the ability to tell this selector what kinds of resolutions it will accept and what kinds it cannot use. F x a paint or video program may have some use for HAM, but a word processor won't like it and so on. This seems to me to be a good conceptual baseplate (it's my own idea :-) to discuss pros or cons in software for this or that card. Ok, any jokes aside, this is a proposition for the gfx.device concept. This concept has to be well defined and thought out. I have nor the knowledge or the time to hammer details out, but I trust some of you out there has. Please think this through and compare it (conceptually) to other systems you know about. I will gladly engage in any discussion. By being able to open multiple screens on multiple monitors, apps. could provide the base for visual interaction in a network of Amigas. F x artists put up their art on a clipboard (hmm if the clipboard.device had its own screen...) to be used by the page makeup people and so on. Dream on... > Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" /svante -- Svante Gellerstam svante@kberg.se, d87sg@efd.lth.se