anderson@EUREKA.ucsc.edu (Gary D. Anderson) (03/15/91)
We are working on a program that does animated graphics on a variety of displays (EGA, CGA, Hercules, etc.). We are using Turbo C++ for this project. When we run the profiler, we find that the program is using up to 50% of the cpu time in cleardevice(). Does anyone have any suggestions for a faster method for clearing the screen. We have looked at "undrawing" the screen but that is slower than cleardevice(). We are doing some fairly involved floating point calculations on the fly so we need to speed up the graphics as much as possible to have smooth animation. Gary D. Anderson anderson@secs.ucsc.edu Thimann Laboratories, Department of Chemistry University of California, Santa Cruz CA 95064
dfoster@jarthur.Claremont.EDU (Derek R. Foster) (03/15/91)
In article <13431@darkstar.ucsc.edu> anderson@EUREKA.ucsc.edu writes: > > We are working on a program that does animated graphics on a variety >of displays (EGA, CGA, Hercules, etc.). We are using Turbo C++ for this >project. When we run the profiler, we find that the program is using up to >50% of the cpu time in cleardevice(). Does anyone have any suggestions for >a faster method for clearing the screen. We have looked at "undrawing" the >screen but that is slower than cleardevice(). We are doing some fairly >involved floating point calculations on the fly so we need to speed up the >graphics as much as possible to have smooth animation. Instead of actually "undrawing" the screen line-by-line, you might try undrawing it in blocks, for instance if you have a bunch of detailed objects in a small area, just erase a rectangle around that area, using built-in routines of Turbo C++, instead of erasing the entire screen. On EGA/VGA's, with a great deal of effort and assembly language, you can use the hardware's ability to clear eight pixels at a time, plus a set of new drawing routines (of your own design) which record which sets of eight pixels need to be cleared, to do quite rapid erases. Thus, a selective erase of the screen would be performed from a list that was prepared during the original drawing, but the erase would be performed eight pixels at a time instead of the one-at-a-time that was used to draw the original. Of course, the points to be plotted do not need to be recalculated, since they were saved in memory the first time. (Even a line drawing routine does calculations. These can be avoided the second time around at the expense of large amounts of memory. Of course whether this is worth it is a question that you will have to ask yourself.) This is not a pretty or an easy solution, but it can be quite effective. Also, the process of writing or modifying your own routines can increase your speed in other respects. For instance I easily wrote a pixel-plotting routine that was twice as fast as the putpixel() supplied with Turbo C. I'm not really sure why - it was probably something to do with unnecessary error checking, clipping, far function calls, etc. performed by the Turbo C version. I suspect that many other functions could be improved similarly, sacrificing ease-of-use and error-resistance for speed. It's hard to answer a question like this without more detail. What kind of animation are you doing? Wire frames? Solid shapes? Raytracings? The strategies for these differ. How much of what is to be drawn could be figured out in advance and perhaps saved to a disk file, or stored in memory somewhere? How much of the screen is occupied by these animations? How much changes between successive frames? Do some parts remain constant? Do the new images overlap the old? (There are ways to avoid having to erase the overlapped parts of successive solid images, for instances.) Oh, by the way, this isn't about cleardevice, but another thing that sometimes helps speed programs like this up is to replace slow floating-point functions with faster ones involving large table lookups and possibly linear approximation (especially true for functions composed of several subfunctions, like atan2(sin(tan(x)),sin(cot(y))), etc. This function could be replaced with a single two-dimensional table lookup, with the table calculated beforehand or perhaps read in from disk before the animation even starts.) >Gary D. Anderson anderson@secs.ucsc.edu >Thimann Laboratories, Department of Chemistry >University of California, Santa Cruz CA 95064 I don't read this newsgroup often, so if you want more information, please email me. I hope this helps! Derek Riippa Foster