wirehead@oxy.edu (David J. Harr) (10/20/90)
I am doing some graphics programming, and I am replacing some of the QuickDraw bottlenecks to get increased performance. Taking a look at issue #3 of d e v e l o p, there is an article by Guillermo Ortiz on the 8.24 GC, he states that whenever possible, if the bottlenecks are replaced that the application that replaced the bottlenecks should call the originals through the trap dispatcher to ensure compatibility. Now, I am missing something here. If I replace the bottlenecks to increase speed, don't I just shoot myself in the foot by calling the very routine that I am trying to speed up when I am finished doing my speedy drawing? I want to support the accelerator cards and ensure that the people who buy them are not hurt by my replacing the routines, but I'd also like to run faster on those machines without acceleration. If anybody can tell me exactly what Mr. Ortiz is referring to or can direct me to more specific literature on replacing QuickDraw bottlenecks, I'd be appreciative (I already know about IM I, I have read everything about bottlenecks in there several times.) advaTHANKSnce David The preceding has been another fine product of the warped mind of wirehead@oxy.edu
zellers@prisoner.Eng.Sun.COM (Steve Zellers) (10/20/90)
In article <117652@tiger.oxy.edu> wirehead@oxy.edu (David J. Harr) writes: >if the bottlenecks are replaced that the application >that replaced the bottlenecks should call the originals through the trap >dispatcher to ensure compatibility. Now, I am missing something here. If I >replace the bottlenecks to increase speed, don't I just shoot myself in the >foot by calling the very routine that I am trying to speed up when I am >finished doing my speedy drawing? I want to support the accelerator cards >and ensure that the people who buy them are not hurt by my replacing the >routines, but I'd also like to run faster on those machines without >acceleration. What do you mean, plugging your own bottlenecks in for speed? Is your code to render a line on the framebuffer FASTER than apples? Re-read it again, I don't think you're doing quite what you think you are. Bottleneck plugging is most useful when you want to examine each individual object - if you then want this to be rendered, you should proceed to call StdLine, etc. If you don't want it rendered, you don't need to daisy chain it. -- ------------------------------------------------------------------------ Steve Zellers zellers@prisoner.sun.com "All you slimy fruitcakes in San Fransisco are going to find out how to get to 180 and the letter 'G'. I repeat, there is No Other Possibility."
deadman@garnet.berkeley.edu (Ben Haller) (10/20/90)
In article <117652@tiger.oxy.edu> wirehead@oxy.edu (David J. Harr) writes: >if the bottlenecks are replaced that the application >that replaced the bottlenecks should call the originals through the trap >dispatcher to ensure compatibility. Now, I am missing something here. If I >replace the bottlenecks to increase speed, don't I just shoot myself in the >foot by calling the very routine that I am trying to speed up when I am >finished doing my speedy drawing? I want to support the accelerator cards >and ensure that the people who buy them are not hurt by my replacing the >routines, but I'd also like to run faster on those machines without >acceleration. In article <1562@exodus.Eng.Sun.COM> zellers@prisoner.Eng.Sun.COM (Steve Zellers) writes: > What do you mean, plugging your own bottlenecks in for speed? > Is your code to render a line on the framebuffer FASTER than > apples? Re-read it again, I don't think you're doing quite what > you think you are. Why do you ask with such incredulity? Do you *really* think Apple's code is the fastest possible graphics code? I've written a routine for drawing lines that achieves up to an 11x speedup compared to Apple's code (16 color mode, black only. Any color line, I got a 9.6x or something speedup). And very often, you have additional knowledge that allows a speedup if it's used in the algorithm correctly (like the additional spped I got with the special knowledge that I was drawing a black line). I know Solarian II wouldn't be anywhere *near* fast enough if I were using CopyBits... Now of course it is silly to imagine code beating an accelerator card. So even if you hand-code your graphics, it's probably a good idea to check and see if QuickDraw is faster, and if it is, use it. But if it isn't...and you know how to do the same job better...why not do it. I'm really sick of using QuickDraw. It's slow, and it produces mathematically incorrect results. Myself, the only question I would as of David is, why patch the bottlenecks? Why not just do your stuff directly? As Steve correctly says, the bottlenecks are primarily for modification and interpretation of calls, not for total *replacement*. -Ben Haller (deadman@garnet.berkeley.edu)
CXT105@psuvm.psu.edu (Christopher Tate) (10/20/90)
Serious question coming up.... In article <1990Oct20.044902.11853@agate.berkeley.edu>, deadman@garnet.berkeley.edu (Ben Haller) says: > > Now of course it is silly to imagine code beating an accelerator card. So >even if you hand-code your graphics, it's probably a good idea to check and >see if QuickDraw is faster, and if it is, use it. But if it isn't...and you >know how to do the same job better...why not do it. I'm really sick of >using QuickDraw. It's slow, and it produces mathematically incorrect >results. ^^^^^^^^^^^^^^ ^^^^^^^^^ Personally, I'm shocked. The Quickdraw chapter of IM I goes to *SUCH* great lengths talking about the mathematical foundation of QuickDraw, and now I discover that it's a lot of hoo-haw.... What are the documented shortcomings of QuickDraw along these lines? IM claims (of course) that if you're careful, you'll never suffer from "end- point paranoia" or any such malady, but just what is *really* going wrong in there? ------- Christopher Tate | | In space, no one can cxt105@psuvm.psu.edu | hear you sneeze. {...}!psuvax1!psuvm.bitnet!cxt105 | cxt105@psuvm.bitnet |
zellers@prisoner.Eng.Sun.COM (Steve Zellers) (10/21/90)
In article <1990Oct20.044902.11853@agate.berkeley.edu> deadman@garnet.berkeley.edu (Ben Haller) writes: >Why do you ask with such incredulity? Do you *really* think Apple's code is >the fastest possible graphics code? Mainly because I don't trust anyone _other_ than apple to produce code that will work with future machines (or systems) - I don't want to have to stop using a program because I happen to upgrade my machine (happens about once a year) and the author decided that quickdraw was too slow for his app to run. If you can afford to ship a new version of your program everytime apple releases a new machine that breaks your code, fine. Patch away. Having a game break is much less of a problem than having a program that I need to use to do my work stop working. -- ------------------------------------------------------------------------ Steve Zellers zellers@prisoner.sun.com "All you slimy fruitcakes in San Fransisco are going to find out how to get to 180 and the letter 'G'. I repeat, there is No Other Possibility."