Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!unido!mpirbn!p554mve From: p554mve@mpirbn.UUCP (Michael van Elst) Newsgroups: comp.sys.amiga Subject: Re: Graphics.library (was transputer board) Message-ID: <891@mpirbn.UUCP> Date: 10 Apr 90 17:25:15 GMT References: <02602.AA02602@sosaria.imp.com> <8612@hubcap.clemson.edu> <5845.261cc9b7@vax1.tcd.ie> <28715@cup.portal.com> <5849.26208c08@vax1.tcd.ie> Reply-To: p554mve@mpirbn.UUCP (Michael van Elst) Organization: Max-Planck-Institut fuer Radioastronomie, Bonn Lines: 20 In article <5849.26208c08@vax1.tcd.ie> rwallace@vax1.tcd.ie writes: >To be sure, given that you have to do stuff with multiple windows, menus etc. >the graphics library routines aren't that inefficient. The problem is the same >routines have to be used even if you've opened your own custom screen, are >using no menus and could just transfer everything straight into video RAM. >There should be a separate set of routines for that and given that there aren't >and that you need speed, you have to do things yourself. Well, there is a speed difference between drawing into a window and drawing into a screen. All those clipping and locking checks are skipped when drawing into a screens rastport. Nevertheless, the current routines did one thing that made them 'safe' to use. They work synchronous so that you can free the bitmaps they are working on after the call returns. An optimized routine could use the time and calculate the next blit in advance. -- Michael van Elst p554mve@mpirbn.mpifr-bonn.mpg.de