Path: utzoo!utgpu!watmath!watcgl!electro!ignac From: ignac@electro.UUCP (Ignac Kolenko) Newsgroups: comp.sys.atari.st Subject: Re: More Performance Specs Message-ID: <999@electro.UUCP> Date: 5 Aug 89 21:51:44 GMT References: <15602@watdragon.waterloo.edu> <1989Aug3.201227.18486@sj.ate.slb.com> Reply-To: ignac@electro.UUCP (Ignac Kolenko) Organization: Electrohome Ltd., Kitchener, ON Lines: 62 In article <1989Aug3.201227.18486@sj.ate.slb.com> greg@sj.ate.slb.com (Greg Wageman) writes: >If QuickST is intercepting certain traps into TOS, and replacing the >underlying routines with its own, it's possible that calls which would >normally exercise the blitter never get there when QuickST is installed. > >Remember that no applications code has to change to make use of the >blitter; "Blitter-TOS" uses the chip if it exists and otherwise performs >the blits in software. Now if QuickST replaces some (many?) of these >routines, and doesn't itself use the blitter, then having a blitter >won't help except on calls that QuickST doesn't trap that do use the >blitter. This seems to be the case with some GEM calls. > >Darek & Co. could probably get still better performance if they wrote >a version of QuickST that uses the blitter... this is something we have been grappling with quite a bit lately since we are continuously looking for ways to increase GEM speed. the blitter is basically good for one thing: copying and clearing of large rectangular areas. i believe, and correct me if i'm wrong, but most of the work that goes on in GEM based programs is usually the opening of windows, drawing dialog boxes and alert boxes, or, getting down to the nitty gritty, simply lots of text plotting and line drawing (ie: boxes, menus, dialog buttons). the blitter does not do any of these things, simply the blitting (copying) of one rectangular area to another, and clearing (or filling??) or rectangular areas. thus, myself and darek chose to rewrite the text plotting and line drawing algorithms used in the Atari ROMs so that those functions would run at their peak performance. we have left the copying of bit blocks to the operating system since this is NOT done as often as line drawing or text plotting. as for the scroll test, we did indeed write our own scroll routine, since the majority of st owners do not have the (legendary??) blitter chip, and that our 127% (or whatever the latest stats say) is much better than leaving the operating system to do it. the blitter is about 3-5% better in this case, but in reality, how often do you scroll complete screenfuls of VT-52 text?? therefore, rather than try to detect the presence of the stupid blitter, and then set up all the idiotic parameters needed to do a blit, we call our much simpler routine inside QuickST to do the screen blit for scrolling the screen. sure, blitter owners may loose 5% for screen scrolls, but the savings in code space by not worrying about the blitter i think more than justified not using the blitter (remember, on every GEM call we would have to test for the presence of the blitter, which would impair performance slightly over what we have now, for very little gained. and since more people do NOT have a blitter than vice versa, faster code was deemed more important than blitter compatibility.) i hope that straigtens out the blitter controversy with Quick ST. now if someone (like at atari) is willing to send me a blitter to put in my 1040ST, then maybe, just maybe, we could re-consider .... :-) :-) -- =====Ignac A. Kolenko (The Ig) watmath!watcgl!electro!ignac===== co-author of QuickST, and the entire line of Quick Shareware!!!! "I don't care if I don't win, 'cause I don't care if I fail" from 'Youth Of Today' by SUBURBAN DISTORTION