>In the test below, POKE _is_ a slowpoke, half the speed of the byte-record >assignment method. A speedup factor of two is well worth having, and >there's no special penalty of incomprehensibility or code length. You must >have been testing something different? > >Robert P. I was inverting a bitmap then. Perhaps the subtraction portion of my test then nullified any readily apparent gains. Here are two filters similar to what I used, except they poke the values your recent test did. You will need to install them into a gWorld tester, and they assume a previous noting of the Base Address and Rowbytes for a Robert Purves standard gDrawGWorld ptr. I get 5-6 ticks for Test 1, 3-4 ticks for Test 2 with a roughly 600 x 400 image using the FB II runtime on my 240 Mhz Umax 603ev. Now that might seem like a big difference, but it isn't (for me). :) Because nobody is going to miss 2-3 ticks visually. Proportionally, the difference _is_ large, but the total ticks to start with are not all that great, so it is basically imperceptable. Just filtering an image, the setting isn't all that big a slowdown. I can't tell the difference looking without a tickcount number. Now if I was animating, I would be worrying about the ticks a bit more. If you really want to help, I can send you my Median filter, it is a dog! Runs a 3x3 kernel to grab 9 pixels (32 bit gWorld) sorts the luminosities, and picks the middle one, number 4 in a 0-8 stack. Then sets the middle pixel of the kernel to whatever pixel R and G and B that the sort result points to. Wipes out noise for those who would wonder why use such a beast. 3x3 kernel: 1 2 3 4 5 6 7 8 9 Pixel 5 is the Main pixel. Each of the respective pixel's RGB's are averaged to get a luminosity component, then sorted by that. Say pixel 7 is pointed to by the sort as having the middle value of all of the 9, now set Pixel 5 to the respective RGB's of the original input RGB's of Pixel 7. Do this for the whole image. Some image filter operations work best when the source pixels are a copy of the image being worked on. Median is one of them. Getting from and setting to the same image results in extra blurring and loss of detail otherwise. For y = 0 To GRect.bottom-1 For x = 0 to GRect.right-1 Do Median Magic Next x Next y As you can see, there is a bit of overhead in all of this. Lot of papers written on doing this fast. . Robert Covington '//////////// Bob D. Covy's Tester FN's Local FN TestFilter DIM @tmpWorld as long, @tmpDevice as long DIM curPixelM as ptr DIM yy as int , xx as int DIM StartTicks as Long DIM EndTicks as Long Call GetGWorld(tmpWorld,tmpDevice) Call SetGWorld(gDrawGWorld,0) StartTicks = FN TickCount FOR yy=0 TO (gRect.bottom-1) FOR xx=0 TO (gRect.right-1) curPixelM = gBaseAddr + (yy * gRowBytes) + (xx*4) Poke curPixelM+1, 77 Poke curPixelM+2, 66 Poke curPixelM+3, 55 Next xx Next yy EndTicks = FN TickCount - StartTicks Call SetGWorld(tmpWorld,tmpDevice) END FN = EndTicks Local FN TestFilter2 DIM @tmpWorld as long, @tmpDevice as long DIM curPixelM as ptr DIM yy as int , xx as int DIM StartTicks as Long DIM EndTicks as Long Call GetGWorld(tmpWorld,tmpDevice) Call SetGWorld(gDrawGWorld,0) StartTicks = FN TickCount FOR yy=0 TO (gRect.bottom-1) FOR xx=0 TO (gRect.right-1) curPixelM = gBaseAddr + (yy * gRowBytes) + (xx*4) curPixelM.1`` = 77 curPixelM.2`` = 66 curPixelM.3`` = 55 Next xx Next yy EndTicks = FN TickCount - StartTicks Call SetGWorld(tmpWorld,tmpDevice) END FN = EndTicks