jdk@cshlab.bitnet (02/16/89)
I having trouble writing pixels on the screen from an unsigned char array. pw_put works but is INCREDIBLY SLOW. I'm on a sun 4/260 Version 4.0. Color Display. Please E-mail me directly JDK@CSHLAB.BITNET Thanks for any tips.
phill%MED-IMAGE.COMPSCI.BRISTOL.AC.UK@cunyvm.cuny.edu (03/02/89)
> I having trouble writing pixels on the screen from an unsigned char array. > pw_put works but is INCREDIBLY SLOW. I'm on a sun 4/260 Version 4.0. > Color Display. Are you using locking/batching - the appropriate one of these (which one depends on whether you are using retained or non-retained pixrects) causes *dramatic* speed increases. See pw_lock() & pw_batch_on()/pw_batch_off() in SunView Programmers' Guide. Phill Everson Medical Imaging Dept Comp Sci University of Bristol, UK
Kemp@dockmaster.arpa (03/09/89)
>> Question on *slow* operation of pw_put > Advice on proper use of
batch and lock
Proper batching/locking is necessary for performance, but even then
writing individual pixels with pw_put is going to be slow. If at all
possible, you should create a memory pixrect that points to your array of
data and then copy the whole array to your pixwin. Of course this assumes
that you want to manipulate a compact region, not scatter a thousand
points of light randomly about the screen.
We have gotten acceptable speed from a 3/60 and excellent speed from a
3/160 with Graphics Processor in an application that scrolls an image (a
spectrogram in this case) by copying the pixwin to itself with a
horizontal offset and then copying in the new data from a memory pixrect.
A 4/280 should be able to do even better.
Dave Kempknudsen@ihlpl.att.com (Knudsen) (03/23/89)
Kemp@dockmaster.arpa writes: > Proper batching/locking is necessary for performance, but even then > writing individual pixels with pw_put is going to be slow. If at all > possible, you should create a memory pixrect that points to your array of > data and then copy the whole array to your pixwin. Of course this assumes > that you want to manipulate a compact region, not scatter a thousand > points of light randomly about the screen. A 1000 points is structly bush league ;-). My application writes hundreds of thousands of random pixels to the screen. But NOT really randomly; instead more like a slow-motion pciture of a raster scan. Since I write many pixels at a time to one narrow rectangle of the screen, Batching gives me very good performance. As I understand it, pw_batch(N) buffers N raster_ops into the retained pixwin and then figures out the minimal bounding pixrect for those N locations, then copies that to your graphics screen. The smaller that rect, the faster the update. Therefore, if your program works with compact regions (or can be restructured to) as suggested above, then chances are that your performance under plain old batching will improve to where you can omit the explicit pixrect copying and let batch do the dirty work. But as Dave Kemp says, pw_put(one_lousy_pixel) is a last resort; you should try to use predrawn images (as he days), vectors, or a pix_list or whatever they call that list of individual points to be set. Anyway, we'd both advocate concentrating on one neighborhood at a time. BTW, my batching discussion does not apply to Dave's final example using scrolling , which should be done as he says. Mike Knudsen Bell Labs(AT&T) att!ihlpl!knudsen "Anyone can build a conservative design, given liberal resources." -- MJK