Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!apple!sun-barr!decwrl!fernwood!portal!cup.portal.com!phorgan From: phorgan@cup.portal.com (Patrick John Horgan) Newsgroups: comp.sys.amiga Subject: Graphics.library (was transputer board) Message-ID: <28715@cup.portal.com> Date: 8 Apr 90 19:50:27 GMT References: <02602.AA02602@sosaria.imp.com> <8612@hubcap.clemson.edu> <5845.261cc9b7@vax1.tcd.ie> Organization: The Portal System (TM) Lines: 23 Russell Wallace said: |All graphics software that needs to do anything FAST (i.e. animation) accesses |the video RAM and probably the blitter & copper directly because the graphics |library routines are much too inefficient. I used to think this too, and spent long hours when I was in college dis- assembling graphics library routines and commenting them so I could figure out what they were doing, (also because some of the blitter docs in the old RKMs were wrong and I wanted to see how you were REALLY supposed to draw lines:). Graphics is a bit of a specialty with me and I was able to recognize the algorithms used. They really use efficient algorithms. You're right that there is a lot of overhead, but it's not because the code is bad, or the algorithms inefficient. The real problem is that the routines must be general purpose. The routines must work in a multi-window environment. This means that you have a damage-list and complex clipping must be done for almost any graphics call. This takes time. The clipping routines are efficient though:) I was only able to speed up line-drawing using the blitter directly by assuming that my window would always be on top. One way to make things speed up in general is to draw into non-displayed bitmaps with no damage lists, and when done blit the whole thing at once to your display. Patrick Horgan phorgan@cup.portal.com