🚀 go-pugleaf

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