Pixel Bender 3D and the languages like it like HLSL, GLSL, and GLSL/ES usea kind of parallelism called gather. To calculate a particular value,such as a pixel or a vertex, the system looks at values which are in somesense "nearby". The number of values produced, however, is not small. Inthe case of an image processing use of a gather language, you generate allthe pixels in a requested portion of the image.It sounds like what you want to do is something called scatter, where youtake the values under consideration for a particular point, make adecision about them, and then put (accumulate) that decision in a placewhich can also be affected by another of these parallel computations. Aclassic scatter problem is taking an image histogram where you divide upthe color space into a finite number of bins and then calculate how manypixels fall into each bin.There are some tricks you can use to use a gather model to produce scatterlike information through repeated reducing calculations, but it's not aparticularly simple process and I'm pretty fuzzy on the details. If youwere writing for the desktop, I'd suggest you have a look at GPGPUprogramming APIs like OpenCL, CUDA, or DirectCompute. Unfortunately,GPGPU on mobile is in a completely nascent stage right now and the capabilities ofmobile parts is the space we're focusing on most heavily with Molehill and Pixel Bender 3Din this go-around.Chuck.
I realized that the example language and runtime I called out are specifically the 3D variant of Pixel Bender and the upcoming Flash player with 3D support called molehill.
That said, my comments are still accurate for the Flash Pixel Bender 2D support and the Pixel Bender support via toolkit / AfterEffects / Photoshop. They all follow the same gather model. We are making some use of scatter in AIF for AfterEffects & Photoshop, but not in a way that is at present programmable via Pixel Bender.