Думаю, проблема в том, что вы действительно сравниваете Pixel Bender с собственным кодом игрока, а не с «actioncript». Я сомневаюсь, что Pixel Bender когда-нибудь победит в этом сценарии.
масштабирование, которое происходит здесь destBmd.draw( srcBmd, mx );
, кодируется непосредственно в плеере; это, вероятно, так быстро, как вы можете получить (используя эквивалентный алгоритм). С другой стороны, ваше ядро, по крайней мере, должно быть сначала скомпилировано (или JIT-скомпилировано), чтобы работать (возможно, есть ряд других причин, по которым оно будет медленнее; хотя я не знаю много о специфике).
Прочтите этот пост из блога инженера Flash Player :
Давным-давно вернулся во Flash Player
8 дней у нас была идея добавить
универсальный способ создания растровых фильтров. Жесткий
кодирование растровых фильтров, как мы сделали для
Flash Player 8 не только не
гибкий, но имеет бремя добавления
огромное количество нативного кода в
игрок и необходимость оптимизировать его для
каждая платформа. Вопрос для
мы всегда были такими, как ты
Автор таких универсальных фильтров. Различный
идеи плавали вокруг, но в
конец был один камень преткновения: мы
не было языка и компилятора. После
Слияние Macromedia с Adobe
Flash Player и Adobe Pixel
Бендерская команда собралась вместе и мы
наконец то, что нам было нужно: язык
и компилятор.
Таким образом, в основном Pixel Bender работает быстрее, чем манипулирование пикселями непосредственно в Actionscript. Он превзойдет эквивалентный миллион вызовов setPixel и getPixel. Но это будет не быстрее самого игрока (опять же, по тому же алгоритму).
В некотором смысле, вы пытаетесь написать, скажем, светящийся фильтр в PB. Конечно, это круто, и вы можете многому научиться у него, если вы заинтересованы в обработке изображений. Но если ваш фильтр предназначен для работы так же, как собственный фильтр, в этом нет особого смысла, кроме образовательных целей: собственный фильтр будет быстрее и уже доступен без дополнительной строки кода.