This content has been marked as final. Show 3 replies
Well, I have now successfully set up the shader using applyfilter. The problem was applyfilter overwrite the shader's first input image using the bitmapdata given to it as a parameter, furthermore it forcefully requires this first input image to have four channels (image4), and the output pixel also is forced to having 4 channels (pixel4). This gave some pretty cryptic error messages.
After adjusting, it works, but the results are very disappointing. The exact same shading filter is now around five times slower! And, the same overhead on starting it is still there even on tiny output images with just four pixels.
Filtering a 2x2 pixel image through BitmapData.applyFilter takes about 250 milliseconds now, which alone would set my framerate down to a crawling 4 FPS. This clearly seems wrong, so I am wondering if I am doing this right..?
Filtering a 1024x1024 image takes about 500 milliseconds, so the overhead of starting a applyFilter seems huge... Is it recompiled every time I change a parameter?
Filtering a 1024x1024 image using the exact same filter through shaderjob takes merely 100 milliseconds. But I met another problem with shaderjob now, it crashes my browser after I have finished around 10 jobs. Seems like this is related to the size of the texture being processed though, if I process 64x64 textures it can finish all 256 of them.
The applyFilter seems quite stable though, as long as I only use one filter. If I have several filters, filtering through applyFilter also crashes the browser. But, I do not understand why it needs to be five times slower than running the exact same filter via shaderjob?
Are there any other alternatives to shaderjob? It seems I can not use it at all now, because it is so unstable..
For the heck of it, I rewrote the shader filter using AS3 instead, to do benchmarking. My shader is not too complex, but it requires things like mixing colors, doing various math on the individual color components and linearly sampling input images, things that AS3 code is not good at but which PixelBender shines at.
I had to rewrite many of the shader functions in AS3 for this purpose, like "mix" and "samplelinear", which I thought would be much slower in AS3 than native PixelBender code.
Well, to my surprise: For smaller textures, the shader I wrote in AS3 outperforms the PixelBender shader when applied using applyFilter!
For larger images, PixelBender catches up from its delayed start and is faster.
Here are my benchmarks, AS3 vs PixelBender. The measured times is the average after 256 runs or a crash/timeout. ShaderJob always crashes after 10-20 passes (sooner if the images to be shaded are larger). I did verify all the three ways for shading produces the exact same output though.
Size - PB ShaderJob - PB applyFilter - AS3
2x2 - 70ms - 204ms - 0ms
64x64 - 81ms - 206ms - 19ms
128x128 - 79ms - 198ms - 74ms
256x256 - 83ms - 204ms - 293ms
512x512 - 93ms - 211ms - 1168ms
1024x1024 - 111ms - 478ms - 4713ms
So, shaderjob wins hands down once it gets started, but its useless since it crashes. Also the long warmup time is killing performance. :(
I really cannot understand why shaderjob is so much faster than applyfilter though, I am using the exact same shader code. Am I doing something wrong here? How to avoid having shaderjob crash, or speed up applyfilter?
I'm trying to get someone from the Flash team into the discussion to follow up. This is dealing with some intricacies of Flash beyond me right now.